<p>It is worth separating your Continuous Integration "Build" from your Continuous Deployment "Pipeline".  For the build portion, CircleCI seems to be your tool of choice, for the latter I recommend using something like AWS CodeDeploy which natively supports <a href="http://docs.aws.amazon.com/codedeploy/latest/userguide/getting-started-wizard-blue-green.html" rel="noreferrer">Blue-Green Deployments</a>, for completeness you can use CircleCI to orchestrate AWS CodeDeploy:</p>

<p><a href="https://i.sstatic.net/Zwsh1.png" rel="noreferrer"><img src="https://i.sstatic.net/Zwsh1.png" alt="Build and Deployment Pipeline"></a></p>

<p>Separating your pipeline phases has several benefits:</p>

<ol>
<li>You only need to compile/test once from the <code>master</code> branch; then promote the packages through the Artefact Repository.</li>
<li>Your packages are stored forever in an Artefact Repository, for example <a href="https://www.sonatype.com/nexus-repository-sonatype" rel="noreferrer">Sonartype Nexus</a> or <a href="https://www.jfrog.com/artifactory/" rel="noreferrer">JFrog Artifactory</a>, this means you can reproduce an old build as you have the specific packages used for deployment.</li>
<li>CodeDeploy will handle the release patterns for you without having to think too much about how to achieve Blue-Green Deployments.</li>
</ol>

<p>It is also worth stating that you can model the whole pipeline in <a href="https://en.wikipedia.org/wiki/Application_release_automation" rel="noreferrer">Application Release Automation</a> tools such as BuildMaster or Nolio.  Personally, I prefer to build my pipelines from multiple 3<sup>rd</sup> party SaaS solutions.</p>

CC BY-SA 4.0
2024-05-27T21:12:14.233Z
Do you perhaps know how to answer this question as well? Here:  https://devops.stackexchange.com/questions/19340/green-blue-deployments-with-multiple-development-teams
CodeMonkey
CC BY-SA 3.0
2017-04-09T09:00:02.950Z
2017-04-09T11:47:32.377Z
2017-04-09T11:47:32.377Z
Richard Slater
<p>I was told that they easy way out is to have two production branches, master/blue and master/green, git merge action triggers CI to deploy to the matching stacks. Is that possible to do it with single master branch?</p>

<p>Some more details about our stacks.</p>

<ul>
<li>CloudFront, origin set to S3 bucket which serves all the front-end SPA (single page app) static assets.</li>
<li>SPA app talks to AWS API Gateway, which connects AWS Lambda.</li>
<li>AWS Lambda is responsible for db CRUD operations with DynamoDB.</li>
<li>Front-end app and Lambda function each has their own Git repo, Git master branch merge action triggers 2 Circle CI jobs, one copy front-end assets to S3 bucket, the other deploys Lambda with serverless framework.</li>
</ul>

<p>For blue-green deploy, I'm thinking to have 2 instances of S3, API gateway and Lambda function. To make the blue-green switch, we'll need to change origin from one S3 bucket to another, then create invalidations to clear the cache.</p>

<p>To make the single production git branch blue-green deployment to work, Circle CI needs to know is the current active stack is blue or green, copy &amp; paste / deploy to the other stack, if Circle CI is not able to do that, the alternative that I could think of is to somehow put the checkout_current_active_stack action in the git precommit hook? To be specific:</p>

<ol>
<li>(in the git precommit hook) send out a HTTP request to the current active stack API (AWS lambda function, which keep track of the current stack information)</li>
<li>deploy base on the return value ('blue' or 'green')</li>
</ol>

<amazon-web-services><circleci><git-hooks><bluegreen>
How to implement blue-green deployment with one master branch
Joe
# How to implement blue-green deployment with one master branch

(Asked by: username_0 on 2017-04-09)

I was told that they easy way out is to have two production branches, master/blue and master/green, git merge action triggers CI to deploy to the matching stacks. Is that possible to do it with single master branch?

Some more details about our stacks.

* CloudFront, origin set to S3 bucket which serves all the front-end SPA (single page app) static assets.
* SPA app talks to AWS API Gateway, which connects AWS Lambda.
* AWS Lambda is responsible for db CRUD operations with DynamoDB.
* Front-end app and Lambda function each has their own Git repo, Git master branch merge action triggers 2 Circle CI jobs, one copy front-end assets to S3 bucket, the other deploys Lambda with serverless framework.

For blue-green deploy, I'm thinking to have 2 instances of S3, API gateway and Lambda function. To make the blue-green switch, we'll need to change origin from one S3 bucket to another, then create invalidations to clear the cache.

To make the single production git branch blue-green deployment to work, Circle CI needs to know is the current active stack is blue or green, copy & paste / deploy to the other stack, if Circle CI is not able to do that, the alternative that I could think of is to somehow put the checkout\_current\_active\_stack action in the git precommit hook? To be specific:

1. (in the git precommit hook) send out a HTTP request to the current active stack API (AWS lambda function, which keep track of the current stack information)
2. deploy base on the return value ('blue' or 'green')

**Tags:** amazon-web-services, circleci, git-hooks, bluegreen


---

## 1 answers

### Answer by username_1 on 2017-04-09. Score: 5 | Accepted answer

It is worth separating your Continuous Integration "Build" from your Continuous Deployment "Pipeline". For the build portion, CircleCI seems to be your tool of choice, for the latter I recommend using something like AWS CodeDeploy which natively supports [Blue-Green Deployments](http://docs.aws.amazon.com/codedeploy/latest/userguide/getting-started-wizard-blue-green.html), for completeness you can use CircleCI to orchestrate AWS CodeDeploy:

[![Build and Deployment Pipeline](https://i.sstatic.net/Zwsh1.png)](https://i.sstatic.net/Zwsh1.png)

Separating your pipeline phases has several benefits:

1. You only need to compile/test once from the `master` branch; then promote the packages through the Artefact Repository.
2. Your packages are stored forever in an Artefact Repository, for example [Sonartype Nexus](https://www.sonatype.com/nexus-repository-sonatype) or [JFrog Artifactory](https://www.jfrog.com/artifactory/), this means you can reproduce an old build as you have the specific packages used for deployment.
3. CodeDeploy will handle the release patterns for you without having to think too much about how to achieve Blue-Green Deployments.

It is also worth stating that you can model the whole pipeline in [Application Release Automation](https://en.wikipedia.org/wiki/Application_release_automation) tools such as BuildMaster or Nolio. Personally, I prefer to build my pipelines from multiple 3rd party SaaS solutions.

> **Comments:**
> **username_2**: Do you perhaps know how to answer this question as well? Here:  https://devops.stackexchange.com/questions/19340/green-blue-deployments-with-multiple-development-teams  

---

