Blue-green deployment

Blue-green deployment keeps two production environments, one live and one idle; a new version goes to the idle one and all traffic is then switched over.

The technique uses two equivalent environments, called blue and green. One of them serves all users. The new version is deployed to the other one, where it can be tested with production configuration and without user traffic. When it is ready, a setting in a router, a load balancer or a CDN is changed and all traffic moves to it. The previous environment stays intact for a while as the way back.

Example

A single-page application is served from a CDN. Each build is uploaded to its own folder, such as /releases/41/ and /releases/42/. Release 41 is live. The team uploads release 42, runs smoke tests against its direct URL, and then changes the CDN origin path to point to release 42. If something fails, pointing back to release 41 takes one configuration change.

Common misunderstanding

For a frontend, the switch is never as instant as it looks from the server side. Users who opened the application before the switch still run the old JavaScript in their browser tab. When they navigate, the old code may request a lazy chunk that only existed in the old release. If those files are gone, the screen fails to load.

Two practices handle this:

• Keep the files of the previous release available for some time after the switch.
• Make the API accept calls from both frontend versions during that window.

Blue-green covers the frontend artifacts. Database changes and API contracts need their own compatibility plan, since both environments usually share them. The guide on migrating without downtime uses the same idea for cutovers.

Related terms

• Canary release
• Rollback
• CI/CD pipeline