Like canary deployment, blue–green deployment is another type of methodology for safe deployment for production. In canary deployment, we shifted the traffic from one version to the next version gradually until we completely moved it to the latest version. But in the case of blue–green deployment, we create two different environments. One environment is used for going live and the other for staging the new version. So a blue–green deployment setup would create a separate region for staging and production and then route the traffic from one region to another with deploying the latest version.
Let's say that I have a blue region (us-east-1), which is the production region, and that it is live and has the current version of the Lambda functions deployed. Now let's say that I also have a new version out, so I will deploy the Lambda function (the new version) into a green region (us-east-2), and that this will act as my staging environment. I will perform all the testing, and once satisfied, I will redirect all the traffic to the green region (us-east-2). Now that my staging is live, I will go ahead and deploy the latest version to the blue region (us-east-1), and my functions will be tested for bugs and problems. But let's say that, unfortunately, some serious bugs are discovered in the blue region (us-east-1).
Then the code is rolled back, all the traffic is once again pointed to the blue region (us-east-1), and the green region (us-east-2) becomes the staging environment again:
- Blue: $ serverless deploy --stage prod --region us-east-1
- Green: $ serverless deploy --stage prod --region us-east-2