I recently spent some time with some of our most knowledgeable Bluemix people.  We were helping one of our customers explore the possibilities of Bluemix for their organization.  Dan Berg and Scott Rich are two of the sharper guys I know, and they were helping us.  Dan Berg came up with a great technique that enables “Blue/Green” (or rolling) deployments on Bluemix.

You can read his developerWorks article, Automate Rolling Deployments with IDS for Bluemix , and learn how to do this.  The code samples and public Bluemix project that he provides allow anyone to be able to expose this kind of capability for their Bluemix users.  I was going to post my version of the directions for doing rolling deployments in this blog article, but Dan’s is very clear and easy to follow.  He even has links to the Bluemix project with sample code, and links to a post on Blue/Green deployment.

The “meat” of this is the deploy.sh script, but there are changes to the build script (in Ant) as well.  The build script changes that he discusses will copy your updated deploy.sh script to the archiving directory.  This is important to remember (see below).  Dan discusses the deploy shell script, and you should pay particular attention to where you would add the binding of services to your new application.  The nice thing is that you can test this out in a QA pipeline deploy, before you even attempt to do something like this for real.

Just some words of caution as you go through this.  The first is that you need to remember that your build and deployment scripts are under Git control.  This is great, because it allows you to see changes in your scripts, and gives you the ability to rollback to a previous version if necessary.  It also means that as you change your scripts, you will need to COMMIT and PUSH your script changes.  I have made the mistake of editing my scripts in the web browser editor, and then wondering why the changes I make don’t seem to do anything.  It’s because my script changes have not been pushed into the cloud yet.  Another issue is that even after you have pushed your changes into the Git repository, you still need to build the application to get them to execute.  Why?  Because the copy of the deploy.sh script to the archive directory occurs during the build, and the auto-deploy runs from the archive directory.  This isn’t an issue if you have auto-deploy turned on, since the Git commit will automatically kick off a build, which then kicks off an automatic deployment.

The scripts work great.  Ina session with one of our customers last week, the students set up a test that exercised the application being deployed.  It was a simple application, and we just changed some of the titles on a web page.  We then implemented a rolling deployment, and did a push of our changes in Bluemix.  We could then watch as the changes were built, and then auto-deployed in Bluemix.  Their tests noted no interruption of service when we deployed our changes.  It was pretty cool.