Blue-Green deployment with Circle CI

Today I have attended a webinar about Blue-Green deployment with Circle CI.

During the session, the Circle CI engineer show me major features of Circle CI, a typical developer’s workflow with Github and Circle CI, and discover reusable configuration with Orbs.

What’s the Blue Green deployment?

Blue Green deployment is a technique that reduces downtime, by running two identical production environments called Blue and Green. At any time, only one of the environments is live, serving all production traffic. For example, Blue is currently live and Green is idle.

As you prepare a new version of your application, deployment and final stage of testing takes place in the environment that is not live, in this example, Green. Once the application is working in the Green environment, you switch the router so that all incoming requests go to the Green environment - the Blue one is now idle.

This technique can eliminate downtime due to app deployment. In addition, Blue-Green deployment reduces risk: if something unexpected happens with your new version on Green, you can immediately roll back to the last version by switching back to Blue.

There’s still the issue of dealing with missed transactions while the green environment was live, but depending on your design you may be able to feed transactions to both environments in such a way as to keep the Blue environment as a backup when the Green is live. Or you may be able to put the application in read-only mode before cut-over, run it for a while in read-only mode, and then switch it to read-write mode. That may be enough to flush out many outstanding issues.

Once you’ve put your Green environment live and you’re happy with its stability, you then use the Blue environment as your staging environment for the final testing step for your next deployment. When you are ready for your next release, you switch from Green to Blue in the same way that you did from Blue to Green earlier. That way both Green and Blue environments are regularly cycling between live, previous version (for rollback) and staging the next version.

Major features of Circle CI

The application that the engineer have used during the demo: https://github.com/heug/demo-blueskygreenbuilds

Look at the config.yml file, you can see major features that he’s using

• Orbs
• Holding a Workflow for a manual approval.

Orbs

CircleCI orbs are shareable packages of configuration elements, including jobs, commands, and executors. Basically, instead of writing a bunch of line to do works, you can use a shareable package with the provided structure.

In the config.yml, he used Slack Orb. The Slack Orb will send a slack message to reviewer when the code is ready to ship

- slack/notify:
    message: "The latest inventory is ready to ship, please review/approve ASAP! https://circleci.com/workflow-run/${CIRCLE_WORKFLOW_ID}"
    mentions: eugene

There are lot of shareable packages, you can have a look at: https://circleci.com/orbs/registry/?query=

For example, once the tests passed, you want to build a docker image and push to a private registry (AWS ECR). For pushing the image to ECR, you can use ECR Orb

Another example, when you want to deploy the application to Kubernetes (Amazon EKS), by run the Helm chart, you can use AWS EKS Orb

Holding a Workflow for a Manual Approval

Workflows can be configured to wait for manual approval of a job before continuing to the next job. Anyone who has push access to the repository can click the Approval button to continue the workflow.

In the demo, he used it to hold the production deployment, until the reviewer approve.

- hold:
    type: approval
    requires:
      - cloudfoundry/dark_deploy
      - "IE Tests"
      - "Chrome Tests"
    filters:
      branches:
        only: master

Build-Info page

In addition, he shared about the build-info page for application. Basically, the page will show the latest build and commit ID, workflow URL. This will help people in the team know what is the latest build of the application

{
  "buildNum": "329",
  "commitHash": "82f1bbe9fb15a47ad96000a2a4d4df98f97967b0",
  "commitUser": "heug",
  "repoName": "demo-blueskygreenbuilds",
  "workflowGuid": "ebd87be5-580c-4c0d-b4bd-40c14083cfee",
  "workflowUrl": "https://circleci.com/workflow-run/ebd87be5-580c-4c0d-b4bd-40c14083cfee",
  "githubUrl": "https://github.com/heug/demo-blueskygreenbuilds/commit/82f1bbe9fb15a47ad96000a2a4d4df98f97967b0"
}

These informations can get from artifacts.

Convenience Docker images from Circle CI

Before ending the webinar, he shared that the next generation convenience Docker images from Circle CI which is smaller, faster, more deterministic.

image: cimg/ruby:2.6.5

A direct replacement for the legacy CircleCI Ruby image (circleci/ruby)

And if you want to write your own image, then you can use the base image from Circle CI. This is a brand new Ubuntu-based image designed to install the very bare minimum.

image: cimg/base:2020.01

Conclusion

Thanks Circle CI for the webinar, it’s very useful for me, it help me improve the deployment workflow.