Answers: <p>I had a similar question and <a href="https://devops.stackexchange.com/a/1686/2708">this answer</a> was quite helpful. It sketches pattern on how you can do blue-green deployments in Terraform.</p>
  
  <p>But having said that there is no clearly best solution as far as I know. I think the most common approach for your use case would be to have a dedicated "staging" environment that uses a setup that is very close to the production one (sharing the same Terraform modules, but with smaller auto scaling groups). You can use it for the final tests, maybe even route some fraction of the  production traffic over it.</p>
  
  <p>If there are no errors in staging, you simplify roll it out in production and hope that you found most critical bugs before.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-08T14:06:54.190Z
Answers: 2018-03-08T14:06:54.190Z
Answers: Philipp Claßen
Answers: <p>It all depends on how you are deploying your code.</p>
  
  <p>(First, IMHO, I don't think that Terraform is the right hammer for this operation. Terraform responsibility is to build the necessary infrastructure for your application, not to be the tool used for deploying it. But, as always, "the right/best one" will depend on lots of factors and, depending on the case/scale, it may be the "good enough" solution)</p>
  
  <p>My suggestion would be, in summary: </p>
  
  <ol>
  <li>Deploy your application in the "unused" environment </li>
  <li>Test it </li>
  <li>Change the domain name to point to it</li>
  </ol>
  
  <p>Assuming you have 2 AutoScaling groups already configured. One called <code>asg-blue</code> and the other called <code>asg-green</code>. And that the current version resides on <code>asg-blue</code> and in terraform you have an <code>aws_route53_record</code> pointing to it. You would need to follow these steps, each one with a <code>terraform apply</code> before the next: </p>
  
  <ul>
  <li>Deploy the newer version of your application on <code>asg-green</code>
  
  <ul>
  <li>I.e. update everything that is needed to deploy your application version. It may be the AMI you point on your <code>Launch Configuration</code> or any other way that you do exclusively using Terraform.</li>
  </ul></li>
  <li>Test that everything is running as expected
  
  <ul>
  <li>Here you could use the domain-name provided for each ASG/ELB or one already configured on terraform</li>
  </ul></li>
  <li>Update the domain name to pont to <code>asg-green</code> ASG/ELB on the <code>aws_route53_record</code></li>
  <li>Reduce the number of machines needed on <code>asg-blue</code> to don't use too many resources 
  
  <ul>
  <li>Depending on your case you can configure for 0 machines</li>
  </ul></li>
  </ul>
  
  <p>This way you can have your B/G deployment, but for every deployment you'd need at least two manual interventions in your terraform (the deployment of the new version and updating the domain name).</p>
  
  <p>But with this strategy you should <strong>take a lot of care</strong> to not deploy on the current ASG being used. </p>
  
  <p>Of course if your terraform/aws fu is good, instead of reusing ASGs, you could delete and create them as needed.</p>
  
  <p>Hope that this help in having a "big picture" of the entire process. But I'd suggest that you research and start using tools more focused on deployment, like AWS CodeDeploy.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-01-04T16:17:14.427Z
Answers: you might consider also to use terraform workspaces, but still is changing infrastructure not deploy code. Here is the boundry about deployment and infrastructure changes to be defined properly. 
  strictly should not be changed the infrastructure to support new code releases. In some circustances yes.
Answers: Raffaello
Answers: CC BY-SA 3.0
Answers: 2018-01-22T19:47:57.717Z
Answers: 2018-03-08T15:15:18.600Z
Answers: 2018-03-08T15:15:18.600Z
Answers: aderubaru
Body: <p>I have  been trying use terraform for a while . any suggestions/tips on how I can handle blue green deployments . I see how terraform enables it with auto scale groups on aws . But I’d like run some Cucumber acceptance tests on the new Asg before routing traffic to it . Is there a way in terraform to retain the old asg for a period , if In case I need to do a rollback . Can this be accomplished with terraform ... thanks in advance .</p>
  
Tags: <terraform>
Title: Does terraform support blue green deployments and roll backs out of the box
UserDisplayName: Zak
ThreadText: # Does terraform support blue green deployments and roll backs out of the box
  
  (Asked by: username_0 on 2018-01-22)
  
  I have been trying use terraform for a while . any suggestions/tips on how I can handle blue green deployments . I see how terraform enables it with auto scale groups on aws . But I’d like run some Cucumber acceptance tests on the new Asg before routing traffic to it . Is there a way in terraform to retain the old asg for a period , if In case I need to do a rollback . Can this be accomplished with terraform ... thanks in advance .
  
  **Tags:** terraform
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2018-01-22. Score: 8
  
  It all depends on how you are deploying your code.
  
  (First, IMHO, I don't think that Terraform is the right hammer for this operation. Terraform responsibility is to build the necessary infrastructure for your application, not to be the tool used for deploying it. But, as always, "the right/best one" will depend on lots of factors and, depending on the case/scale, it may be the "good enough" solution)
  
  My suggestion would be, in summary:
  
  1. Deploy your application in the "unused" environment
  2. Test it
  3. Change the domain name to point to it
  
  Assuming you have 2 AutoScaling groups already configured. One called `asg-blue` and the other called `asg-green`. And that the current version resides on `asg-blue` and in terraform you have an `aws_route53_record` pointing to it. You would need to follow these steps, each one with a `terraform apply` before the next:
  
  * Deploy the newer version of your application on `asg-green`
    + I.e. update everything that is needed to deploy your application version. It may be the AMI you point on your `Launch Configuration` or any other way that you do exclusively using Terraform.
  * Test that everything is running as expected
    + Here you could use the domain-name provided for each ASG/ELB or one already configured on terraform
  * Update the domain name to pont to `asg-green` ASG/ELB on the `aws_route53_record`
  * Reduce the number of machines needed on `asg-blue` to don't use too many resources
    + Depending on your case you can configure for 0 machines
  
  This way you can have your B/G deployment, but for every deployment you'd need at least two manual interventions in your terraform (the deployment of the new version and updating the domain name).
  
  But with this strategy you should **take a lot of care** to not deploy on the current ASG being used.
  
  Of course if your terraform/aws fu is good, instead of reusing ASGs, you could delete and create them as needed.
  
  Hope that this help in having a "big picture" of the entire process. But I'd suggest that you research and start using tools more focused on deployment, like AWS CodeDeploy.
  
  > **Comments:**
  > **username_3**: you might consider also to use terraform workspaces, but still is changing infrastructure not deploy code. Here is the boundry about deployment and infrastructure changes to be defined properly.  strictly should not be changed the infrastructure to support new code releases. In some circustances yes.  
  
  ---
  
  ### Answer by username_1 on 2018-03-08. Score: 2
  
  I had a similar question and [this answer](https://devops.stackexchange.com/a/1686/2708) was quite helpful. It sketches pattern on how you can do blue-green deployments in Terraform.
  
  But having said that there is no clearly best solution as far as I know. I think the most common approach for your use case would be to have a dedicated "staging" environment that uses a setup that is very close to the production one (sharing the same Terraform modules, but with smaller auto scaling groups). You can use it for the final tests, maybe even route some fraction of the production traffic over it.
  
  If there are no errors in staging, you simplify roll it out in production and hope that you found most critical bugs before.
  
  
  ---
  
  