Blue-Green Deployments - Continuous Deployment and Fast Rolling Back

Quite some time ago Martin Fowler wrote about a pattern he had observed that he named “blue green deployment”. The core idea is that you can deploy to at least 2 parallel production class environments, and then switch between then as a way of “promoting” one environment to production.

The benefits are clear for continuous deployment - where you can confidently deploy to a production grade environment, and then cut over, or cut back, quickly. Reducing the cost of a rollback to zero means you can be fearless with deployments (if you want !).

Blue-Green Deployments

I have also seen this used to make sure DR (disaster recovery) environments are kept healthy in more traditional non cloud deployments - in this case, there was concern that, historically, when a DR environment is needed to be used it isn’t actually workable - so one way to keep it healthy and a peer with production is to alternate what you deem as production or DR.

On RUN@cloud we now allow this pattern - this is done by a new feature that allows you to bind addresses to apps, for example:

bees app:proxy:update -a acme-maintenance -al

This now means that points to your acme-maintenance app. So you can do this between any apps - you can have a whole range of them - separate apps, separate IDs - remap your domain name atomically. This allows all sorts of patterns to be implemented - like blue-green deployment, or maintenance mode and more. This stack overflow question gave a sneak peak of this a few weeks back.



That sounds very cool! I'm just wondering how this is integrated with Jenkins? Let's assume I have an app0 (live) and an app1 (stage). Now I make a commit to GitHub, Jenkins compiles the app and deploys it to staging. But wait, how would Jenkins know which one is the staging one right now? Since they "switch" places on each production deployment, as far as I can tell Jenkins has no clue ... manual interaction would be required, wouldn't it? So how would you combine blue-green deployments with continuous integration?

yes - the automatic deployment would need to be modified to make use of this - ie it needs to know about all the ids, and what state things are in etc. In the subsequent google hangout we did - Stephen Connelly even talked about this - he builds the deployer plugins (amongst other things) and he was still thinking about how this stuff could roll into that (he would like to see how people use it first, even by hand, or via other scripting). So basically - the deployer plugin is unaware of this right now - so you would have to jump through some hoops (perhaps having multiple jobs - one for each app (I don't really know). Really - we need to think through how this will sit in the deployer plugin(s) - make it away of this feature etc - and any switching from blue to green is done in Jenkins so it knows what is currently prod (so it can deploy to the other app, and then flip).

There is now a way to automate this even more: And in a jenkins freestyle build, you could have a script that does something like this, to automate: # INSTALL AND CONFIGURE BEES SDK<br />export BEES_HOME=/opt/cloudbees/cloudbees-sdk/<br />export PATH=$PATH:$BEES_HOME<br />if [ ! -d ~/.bees ]; then<br /> bees init -f -a -ep us -k $BEES_API -s $BEES_SECRET<br />fi<br />bees plugin:install com.cloudbees.sdk.plugins:bg-plugin<br /><br /><br /><br /># DEPLOY<br />bees app:bg:deploy -n yourRealApp target/web-webapp.war<br /><br /><br /><br /><br /># WARM NEW SERVERS<br />echo "Preparing new servers for router switch over..."<br />for i in {1..50}<br />do<br /> curl -s "http:///" > /dev/null<br /> sleep 5<br />done<br /><br /><br /><br /><br /># SWITCH ROUTER<br />echo "Switching router over to new servers..."<br />bees app:bg:switch -n yourRealApp -f<br /><br />I will write more about this shortly.<br /><br /><br /><br /><br /># SHUTDOWN OLD SERVERS<br />echo "Shutting down old servers..."<br />bees app:bg:stop -n int -f

Add new comment