Do you deploy application releases manually? Whilst you're deploying, does it cause downtime for your users? When is a good time to deploy that release to your production environment? Is it:
The answer is NEVER. There is never a good time. If you deploy during the day, your users get grumpy. If it's out of hours, your team get grumpy.
So how do you deploy your application at a convenient time for you without users noticing?
ENTER BLUE/GREEN DEPLOYMENTS!
When deploying the latest version of your application, users shouldn't know it's happening. They don't want kicking off the system, or to suddenly receive errors because there's a bug that wasn't picked up during testing.
Blue/green deployments allow you to test your application before switching users over to it. This seems like a good time for me to do some exceptional drawing:
In this example:
A load balancer sits in front of all this infrastructure, making sure users only go to the green instance until blue passes testing.
The idea is all users are routed to the green instance. Hidden away is the blue instance, that only your technical team have access to. They will be testing it and fixing it if there are any bugs, then when they are happy with blue, all users are routed to it. Once there are no users using green, that instance is terminated. The instance will be no more. It will cease to be. It is an ex-instance!
It is important that blue's infrastructure is the same as green's - we don't want the added uncertainty of different infrastructure. That's not a problem though, because we're using Terraform!
Note that there are other deployment methods such as:
Be sure to think about what you want to achieve first, then look at the different deployment methods to understand which is best for your situation. Blue/green isn't for every situation!
Hang on...I've been typing all this time and haven't mentioned the cloud once?! Let's change that!
The cloud makes blue/green deployments a lot easier to manage. It's possible to route users from one set of instances to another in just a few button clicks, with the bonus of being able to automate the whole process!
A lot of cloud providers offer services to help make it even easier. AWS has CodeDeploy, Azure offers Traffic Manager.
Blue/green with AWS CodeDeploy
I won't provide a proper step-by-step of how to set up blue/green deployments in AWS as they're pretty good at documentation.
There are additional options too, such as Triggers (e.g. CodeDeploy can send an alert to AWS Simple Notification Service, which in turn can send an SMS/Slack message/email when a deployment fails or completes) or Rollbacks (to automatically redeploy the last working release if the deployment fails).
And that's it for the configuration!
The final step is to create a Deployment. Your application needs to be stored in either AWS S3 (AWS' storage service) or GitHub, and the only change needed is adding an 'AppSpec' file to your application package. This file, written in JSON or YAML, contains instructions telling CodeDeploy how to deploy the application, start and stop it, along with how it can check the application is running as expected.
You can't just throw blue/green deployments at your application and wonder why everything is on fire. Look at your release process and application first to make sure they're a good fit in terms of the application itself and your release process.
Imagine you need to release your application right now - does that make you curl up into a ball? Are you crying? Maybe some of this rings a bell:
If you or your team say any of these things, then you should look at your release process first before thinking changing the way you deploy. Releases should be small, and applications decoupled from each other.
So, if your releases currently take hours, have lots of manual steps and all your applications depend on each other, you'll do more harm than good!
Is your application ready for this sort of deployment process? Start by asking:
For sessions - if a user is in the middle of something on an instance that's about to be taken out of load, that user shouldn't notice that they've been switched over to a new one. There are different ways of handling session management. For example, the Panintelligence dashboard currently uses an Apache Tomcat server, so Tomcat's in-built clustering can be used for session management. More information can be found here.
For databases - if you have a database that the application heavily relies on, you can't make huge changes that would cause the existing version of the application to stop working. Changes should be rolled out gradually, but this should be the case for releases anyway!