wr0ngway
commented
6 years ago Sounds like the right plan. I'd probably approach it by generating a standalone aws/codepipeline template that generates the files that is common to all usages of codepipeline, and to parameterize it for a service by ask? in its template.rb. You have to run it separately than the run for service though, which may be ok, but you could always have a second convenience template, named aws/service-codepipeline that depends on both the service and codepipeline templates to force running both in one go if you know that you'll always be using both.
One gotcha at CI runtime is you'll need to either install the rubygem or docker container for the atmos runtime to get the deploy convenience methods. It should work fine if the AWS* auth for the deployer user is in the env, but you might run into issues not having the atmos.yml present from the ops repo if you want to deploy different branches to different accounts. I still need to figure out the best solution to that vs just copying it to the service repo, maybe a central store that always has the latest, or just some extra env vars for CI for it to get account ids.
I haven't tried codepipeline yet, so this will great for incenting me by giving me a quickstart to using it, Thanks!
I am wondering how you would approach integrating CodePipline for CI/CD into a service. When creating a new service it would be nice to also automate the creation of a CodePipline which consists of a CodeCommit repository and a CodeBuild script for building and deploying the new docker container to ECR. Should I create a new atmos template source with a slightly different template name and definition of a service?