<p>I managed to setup an environment that does what I described above. Here are the full details:</p>

<ol>
<li>Launch a template that creates a CodeCommit repository for the
application. This repository will be used to store both the source
code and the CloudFormation (CF) templates to create the required
infrastructure for the application;</li>
<li>Launch a template that creates a CodePipeline pipeline for the
application. The pipeline will deploy a stack for the infrastructure
and one for deploying the code through CodeDeploy (the CodeDeploy
stack will will create a new CodeDeploy Application and deployment
group, and will deploy the latest code to the infrastructure created
previously)</li>
</ol>

<p>The pipeline has a paramater "StackBlueeGreen" that is used to determine whether the stack is the Green or the Blue version.</p>

<p>When the pipeline runs successfully, it will create a separate infrastructure </p>

<blockquote>
  <p>(NameOfTheApplication-B or NameOfTheApplication-G)</p>
</blockquote>

<p>and deploy the code there. The second infrastructure will have its own load balancer listener rule setup with a staging URL </p>

<blockquote>
  <p>(something like URLOfTheApplication-staging.somedomain.co.uk)</p>
</blockquote>

<p>This allows developers to test the new version of the application withuot affecting the previous version. Once developers are happy with the new version, the listener rules for the old and new infrastructure need to be changed manually so that users are now directed to the new infrastructure. If there is an issue with the new version, rolling back is as simple as swapping the load balancer listener rules again.</p>

<p>Finally, the pipeline stack need to be updated: the StackBlueGreen parameter needs to be switched to G/B depending on how it is currently set. If this is not done, next time there is a change, the new version will be deployed on the same infrastructure.</p>

<p>[The setup described above works very well and meets all the requirements outlined in the OP.
An improvement that I would really like to implement is automating the switching of the load balancer listener rule, deletion of the old infrastructure and updating the pipeline stack. I will add to this question if I manage to implement this improvement.
Meanwhile, any input would be much appreciated!]</p>

CC BY-SA 3.0
2018-05-01T12:20:08.040Z
2018-05-01T12:20:08.040Z
Kappacake
<p>I am implementing a CICD pipeline using CodePipeline, CodeCommit, CodeDeploy and CloudFormation (I skipped the build part of the pipeline and am going to commit built code for the moment).</p>

<p>I already have a CloudFormation template that creates the required infrastructure to host the application, a CodeDeploy Application (in a nested stack) and a CodePipeline that gets the source code from CodeCommit, does In-Place deployments via CodeDeploy and finally sends an approval email (in a nested stack).</p>

<p>I would like to implement the following:</p>

<ol>
<li><p>In order to create the required infrastructure to host the application for the first time, I launch a CloudFormation template that creates (I already have this):</p>

<ul>
<li>The required infrastructure to host the application (AutoScalingGroup and Launch Config, TargetGroup and ListenerRules, IAM roles)</li>
<li>CodeDeploy Application and DeploymentGroup (this will be in a nested stack)</li>
<li>CodePipeline pipeline pre-configured to carry out the next steps (this will be in a nested stack)</li>
</ul></li>
<li><p>When source code is committed to CodeCommit, CodePipeline launches a new CloudFormation stack containing the required infrastructure to host the application, then deploys the new version of the code to this stack, without affecting the existing stack for the old version of this application. The new stack will have a listener rule with a different host name, so I can test the application while users keep using the old version;</p></li>
<li><p>Once the code has been deployed, CodePipeline sends an approval email (through an SNS topic and I already have this);</p></li>
<li><p>If the email is approved, the old stack (created in step 1. ) is deleted</p></li>
<li><p>I will manually swap the listener rules for the two stacks to direct users to the new stack created in step 2, then delete the old stack.</p></li>
</ol>

<p>I am struggling to implement step 2 and currently trying to use a Deploy action with a CloudFormation deployment provider to carry out step 2. above. I am struggling to pass the output artifacts (new source code) from the previous stage to the new stack.</p>

<p>Can you provide some guidelines on how to implement <strong><em>step 2</em></strong> ?</p>

<amazon-web-services><continuous-deployment><build-pipeline>
AWS CodePipeline staged deployments
Kappacake
# AWS CodePipeline staged deployments

(Asked by: username_0 on 2018-04-24)

I am implementing a CICD pipeline using CodePipeline, CodeCommit, CodeDeploy and CloudFormation (I skipped the build part of the pipeline and am going to commit built code for the moment).

I already have a CloudFormation template that creates the required infrastructure to host the application, a CodeDeploy Application (in a nested stack) and a CodePipeline that gets the source code from CodeCommit, does In-Place deployments via CodeDeploy and finally sends an approval email (in a nested stack).

I would like to implement the following:

1. In order to create the required infrastructure to host the application for the first time, I launch a CloudFormation template that creates (I already have this):

   * The required infrastructure to host the application (AutoScalingGroup and Launch Config, TargetGroup and ListenerRules, IAM roles)
   * CodeDeploy Application and DeploymentGroup (this will be in a nested stack)
   * CodePipeline pipeline pre-configured to carry out the next steps (this will be in a nested stack)
2. When source code is committed to CodeCommit, CodePipeline launches a new CloudFormation stack containing the required infrastructure to host the application, then deploys the new version of the code to this stack, without affecting the existing stack for the old version of this application. The new stack will have a listener rule with a different host name, so I can test the application while users keep using the old version;
3. Once the code has been deployed, CodePipeline sends an approval email (through an SNS topic and I already have this);
4. If the email is approved, the old stack (created in step 1. ) is deleted
5. I will manually swap the listener rules for the two stacks to direct users to the new stack created in step 2, then delete the old stack.

I am struggling to implement step 2 and currently trying to use a Deploy action with a CloudFormation deployment provider to carry out step 2. above. I am struggling to pass the output artifacts (new source code) from the previous stage to the new stack.

Can you provide some guidelines on how to implement ***step 2*** ?

**Tags:** amazon-web-services, continuous-deployment, build-pipeline


---

## 1 answers

### Answer by username_0 on 2018-05-01. Score: 2

I managed to setup an environment that does what I described above. Here are the full details:

1. Launch a template that creates a CodeCommit repository for the
   application. This repository will be used to store both the source
   code and the CloudFormation (CF) templates to create the required
   infrastructure for the application;
2. Launch a template that creates a CodePipeline pipeline for the
   application. The pipeline will deploy a stack for the infrastructure
   and one for deploying the code through CodeDeploy (the CodeDeploy
   stack will will create a new CodeDeploy Application and deployment
   group, and will deploy the latest code to the infrastructure created
   previously)

The pipeline has a paramater "StackBlueeGreen" that is used to determine whether the stack is the Green or the Blue version.

When the pipeline runs successfully, it will create a separate infrastructure

> (NameOfTheApplication-B or NameOfTheApplication-G)

and deploy the code there. The second infrastructure will have its own load balancer listener rule setup with a staging URL

> (something like URLOfTheApplication-staging.somedomain.co.uk)

This allows developers to test the new version of the application withuot affecting the previous version. Once developers are happy with the new version, the listener rules for the old and new infrastructure need to be changed manually so that users are now directed to the new infrastructure. If there is an issue with the new version, rolling back is as simple as swapping the load balancer listener rules again.

Finally, the pipeline stack need to be updated: the StackBlueGreen parameter needs to be switched to G/B depending on how it is currently set. If this is not done, next time there is a change, the new version will be deployed on the same infrastructure.

[The setup described above works very well and meets all the requirements outlined in the OP.
An improvement that I would really like to implement is automating the switching of the load balancer listener rule, deletion of the old infrastructure and updating the pipeline stack. I will add to this question if I manage to implement this improvement.
Meanwhile, any input would be much appreciated!]


---

