Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2018-05-01T12:20:08.040Z
Answers: 2018-05-01T12:20:08.040Z
Answers: Kappacake
Body: <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>
  
Tags: <amazon-web-services><continuous-deployment><build-pipeline>
Title: AWS CodePipeline staged deployments
UserDisplayName: Kappacake
ThreadText: # 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!]
  
  
  ---
  
  