0
votes

I'm working on migrating our deployment pipeline from TeamCity + Octopus Deploy to AWS Pipeline(using AWS CodeBuild + AWS CodeDeploy). I've been able to setup the whole pipeline for 1 environment. What I'm struggling is promote that deployment to a different environment.

For instance, the initial deployment is carried out in test environment. CodeDeploy agent on test instance handles config transformations (i.e replace connection string etc with test values). Now I want to deploy the same artifacts (without a rebuild) to the production environment so that the agent does the same thing and the application run for production environment.

In Octopus Deploy, this functionality is built-in. You simply click Promote button and select the target environment. Is there a way to achieve the same with AWS CodePipeline service?

2

2 Answers

2
votes

In CodeDeploy, an 'Application' maps to a 'Deployment group' which is where the code will be deployed. A Deployment group can be a set of EC2 instances or ECS/Lambda as well. There is no concept of 'Environment' (dev/test/prod) within this 'Deployment group'.

What you need in AWS world is a CodePipeline with multiple stages for Deployment using CodeDeploy as Deployment provider. These multiple CodeDeploy Applications (in different CodePipeline stages) will map to different Environments (dev/test/etc) as the Deployment Groups of these CD Application will map to different set of instances. The artifact (in CodePipeline) to deploy fed to these Deploy stages should be same and you can use manual approval actions to "gate" the deployment to e.g. Production environment.

0
votes

I'm currently trialing the same migration, and have found it to be not applicable to our current processes, to take full advantage of it, you'd have to change to a more linear or trunk based approach.

As shariqmaws pointed out, there's no environments, but you can akin each Pipeline to an Octopus Channel, so you'd have a Live pipe which would build master, deploy to Staging/UAT, and wait promotion to Live, and you could have a Dev pipe for unstable changes.

That's all fine, but the tricky bit is the Dev/QA branches so easily managed in octopus, we test before merging, so it'd be necessary to either create or alter an existing Dev/QA pipe to point to whatever feature branch you want to deploy for testing, which is not very practical, as you need another pipeline to manage this pipeline!

Octopus is a "automated deployment and release management tool", and CodePipeline is just a continuous integration/deployment tool, so you cannot really replace octopus with it.