Blue-green deployment keeps two identical production environments and moves users from the old one to the new one by switching traffic, not by changing the running system.

First, the basics

A deployment is the act of putting a new version of software where users can reach it. An environment is a complete place where the application runs: servers or containers, network settings, configuration, and connections to other services. Production is the environment that real users use.

Jenkins is a free automation server that builds, tests, and delivers software. A Jenkins pipeline is a written list of steps, stored in a file called a Jenkinsfile. Pipelines are very good at deployments, because deployments are a sequence of careful, repeatable steps.

The two colours

In blue-green deployment, the two environments are simply named blue and green. At any moment, one of them is live, receiving user traffic, and the other is idle. The colours have no meaning except to tell the two apart. After each release, the roles swap: the environment that was idle becomes live, and the old live one becomes the idle standby for the next release.

The steps in one sentence

Deploy the new version to the idle environment, test it there while nobody is using it, switch user traffic to it, watch closely, and keep the old environment ready so you can switch back if needed.

What it gives you

• Little or no downtime: users never see a maintenance page, because the new version is already running before they are moved.
• Testing in a real environment: the idle environment is a production twin, so tests there are realistic.
• Fast rollback: going back is another flip of the switch, not a new deployment.
• Calmer releases: the risky work happens in private, and only the quick switch is visible to users.

Releases used to mean downtime and dread. Blue-green deployment grew out of the wish to make releases boring.

The old way: update in place

In the traditional approach, the team stops the application on the production servers, copies new files over the old ones, runs any database changes, and starts the application again. During that time, the service is unavailable or half-updated. If something goes wrong, the team must repair or reverse the changes while users wait, often late at night and under pressure.

The cost of fear

Because releases were risky, teams did them rarely, and each release contained a large pile of changes. Big releases are harder to test and harder to debug, which made them even riskier. It was a vicious circle: fear led to big, rare releases, which caused the very failures that everyone feared.

The idea takes shape

The blue-green idea is generally credited to practitioners of continuous delivery, and it was popularised by Jez Humble and Dave Farley in their writing on the subject, and described clearly by Martin Fowler. The insight was simple: if you cannot make the release itself risk-free, make it reversible, and do the risky part where users cannot see it. Cloud platforms later made a second environment cheap to create, which turned a luxury into an everyday technique.

Real-world motivation

Many cloud platforms now include features that follow the same idea, such as deployment slots that can be swapped, or environment swaps that exchange addresses between two copies. Teams that release many times a day rely on such techniques, because a strategy that needs a night of downtime does not fit a working day full of releases.

A handful of ideas explain almost everything about blue-green deployment.

Vocabulary table

A blue-green setup has four main parts: the two environments, the router in front of them, the shared services behind them, and the Jenkins pipeline that controls it all.

The players

The router sits in front and sends users to the live environment. The blue and green environments each run a full copy of the application. Behind them, shared services such as the database, message queues, and storage serve both environments. Jenkins builds the artifact, deploys it to the idle environment, runs tests, and asks the router to switch. Monitoring watches both environments and the traffic.

flowchart LR
    U["Users"] --> R["Router or Load Balancer"]
    R -->|"Live traffic"| B["Blue Environment running version 1"]
    R -.->|"No traffic yet"| G["Green Environment running version 2"]
    B --> DB["Shared Database"]
    G --> DB
    J["Jenkins Pipeline"] -->|"1 Deploy new version"| G
    J -->|"2 Test the idle environment"| G
    J -->|"3 Switch traffic"| R
    MON["Monitoring and Alerts"] --> B
    MON --> G
    MON --> J

Reading the diagram

Users always talk to the router, never directly to an environment. The router currently sends everything to blue, which runs version one. Jenkins deploys version two to green, tests it privately, and only then tells the router to switch. Both environments use the same database, which is why database changes need special care, as we will see. Monitoring watches both environments and the pipeline, so that problems after the switch are noticed within minutes.

Where the decisions live

The switch is the heart of the technique. Different platforms offer different ways to build it, each with its own speed and risks.

Common switching mechanisms

Why DNS is the trickiest

DNS is the system that turns names into addresses. Answers are cached by many computers for a time called the TTL, or time to live. If you change a DNS record, some users continue to reach the old environment until their cached answer expires. That makes the cutover gradual and hard to reverse cleanly. Teams that use DNS often lower the TTL well before the release, and keep the old environment running long enough for caches to expire.

Properties of a good switch

Follow one release from a finished build to a completed switch, and see who talks to whom at every step.

sequenceDiagram
    participant J as Jenkins
    participant AR as Artifact Store
    participant G as Idle Environment Green
    participant R as Router
    participant B as Live Environment Blue
    participant M as Monitoring
    J->>AR: Build once and publish versioned artifact
    J->>R: Ask which colour is live
    R-->>J: Blue is live so Green is idle
    J->>G: Deploy artifact to Green
    J->>G: Run health checks and smoke tests
    G-->>J: All checks pass
    J->>J: Wait for human approval without holding an agent
    J->>R: Switch traffic to Green with connection draining
    R->>G: New requests now go to Green
    J->>M: Watch errors and latency for a set period
    M-->>J: Metrics healthy
    J->>B: Keep Blue ready as rollback target

The lifecycle in plain steps

Where the risk hides

Most of the release happens where users cannot see it. The only step that touches users is the switch, and it is short and reversible. That is the secret of the technique: the dangerous parts are moved into private time, and the visible part is made tiny.

Two environments are easy to duplicate. One shared database is not. This is the hardest part of blue-green deployment.

The problem

Both environments usually use the same database, because copying live data between two databases for each release is slow and risky. But the new version of the application may need a different table layout than the old one. If you change the layout for the new version, the old version, which is still live, may break. And if you roll back after users have written data in the new layout, the old version must still understand it.

The rule: every change must work with both versions

The solution is to make database changes backward compatible. At any moment during a release, both the old and the new application version must work correctly with the database as it stands. This is achieved with a technique often called expand and contract, or the parallel change pattern.

Examples

The pipeline’s part

Database changes should be applied by a controlled step of the pipeline, before the switch, using a versioned migration tool. The migrations themselves must be reviewed for compatibility. Jenkins cannot decide whether a change is safe, but it can run the migration once, record it, and stop the release if it fails.

Besides the database, several other kinds of state can cause surprises at cutover.

User sessions

A session remembers who is logged in and what they are doing. If sessions are kept in the memory of one environment, switching traffic logs everybody out, because the new environment knows nothing about them. The fix is to keep sessions in a shared store that both environments can read, or in signed tokens that carry the information themselves.

Caches

A new environment starts with empty caches, so its first requests are slow, and the sudden load can overwhelm the database. This is called a cold start. Reduce it by warming up the new environment before the switch, for example by sending it a sample of realistic requests, and by switching traffic gradually where the platform supports it.

Background jobs and queues

Many applications run background workers that take messages from a queue, or scheduled jobs that run every hour. If both environments run these at once, work may be done twice: two emails sent, two invoices created. Decide which environment runs the workers and schedules, and switch them deliberately with the traffic. Make jobs safe to repeat where possible.

External connections

Other systems may talk to your environment: payment providers sending notifications, partners calling your address, or monitoring tools checking a particular URL. If these point to a fixed environment rather than to the router, they will break or go to the wrong side at cutover. Always give external parties the router’s stable address.

Blue-green is one of several ways to release. Choosing well means knowing the alternatives.

flowchart TD
    S["Choose a release strategy"] --> Q1{"Is downtime acceptable"}
    Q1 -->|"Yes, for example internal tool at night"| RC["Recreate is simple enough"]
    Q1 -->|"No"| Q2{"Can you run a second full environment during release"}
    Q2 -->|"No, too costly or not possible"| RL["Rolling update or canary"]
    Q2 -->|"Yes"| Q3{"Can database changes be made backward compatible"}
    Q3 -->|"No"| FIX["Fix the data approach first or use careful maintenance windows"]
    Q3 -->|"Yes"| Q4{"Need to test with a small share of real users first"}
    Q4 -->|"Yes"| CAN["Blue-green plus a canary step"]
    Q4 -->|"No"| BG["Blue-green deployment"]

How they combine

These strategies are not rivals. Many teams combine them: feature flags for controlling visible changes, blue-green for safe infrastructure switches, and canary steps for gradual exposure. Blue-green answers the question “how do I release safely and undo instantly?” while feature flags answer “who should see this feature, and when?”

Jenkins does not perform blue-green deployment by magic. It orchestrates a sequence of steps that other tools carry out.

What Jenkins is good at

A deployment is a series of careful, ordered steps with decisions between them. Jenkins pipelines excel at exactly that: running steps in order, stopping on failure, pausing for approvals, keeping a log, and using credentials safely. The actual switch is performed by a command or a call to the router, the platform, or a deployment tool, which the pipeline starts.

The stages of a typical pipeline

Principles for the pipeline

• Build once. Never rebuild for production. Promote the same artifact that passed the tests.
• Ask, do not assume. Query the router for the live colour every time.
• Automate the boring parts, and keep a human decision where the risk justifies it.
• Make every step safe to repeat, so a failed run can be started again.
• Keep rollback one click away, in the same pipeline or a companion job.

The package that reaches production must be the very same package that passed the tests. Anything else is a gamble.

What an artifact is

An artifact is the built, versioned result of your code: a container image, a package file, or an archive. It is stored in an artifact registry, a service designed to hold such packages, each with a unique version.

Why you must not rebuild

If the pipeline rebuilds the application for production, the result may differ from the tested build. A dependency may have released a new version, a build tool may behave differently, or a clock-dependent step may produce different output. You would be shipping something that was never tested. The rule is: build once, test that artifact, and promote it unchanged through every environment.

Identity by version

Configuration stays outside

The artifact must be the same for blue and green and for every stage. Differences between environments, such as addresses and credentials, are provided at run time from configuration and secret stores, not baked into the package. Then one package can run anywhere, and nothing environment-specific is hidden inside it.

Deploying to the wrong colour is the most dramatic mistake in this technique. The pipeline must always know which side is live.

The danger

If the pipeline deploys the new version to the environment that is currently serving users, the whole benefit is lost, and users may see a broken release directly. It sounds too silly to happen, but it does, especially when colours are stored in a place that can drift out of date.

Where the truth should live

Ask first, then act

The first step of the deploy stage should be a query to the router: “which environment are you sending users to?” The pipeline records the answer in the log and in the build description, picks the other colour as the target, and refuses to continue if the answer is unclear or contradictory, for example if traffic appears to go to both.

Guard rails

• Refuse to deploy to the live colour. A hard check that stops the pipeline.
• Confirm the idle colour is really idle, by checking that it receives no user traffic.
• Print the decision clearly, for example “Live is blue. Deploying version 2.4.0 to green.”
• Use locks so two pipelines cannot decide at the same time and collide.

The deploy step is the quiet, private part of the release. It should be boring, repeatable, and thoroughly logged.

What happens in this stage

• The pipeline fetches the exact artifact version from the registry.
• It applies backward-compatible database migrations, if the release has any.
• It installs or starts the new version in the idle environment.
• It provides configuration and secrets from the proper stores.
• It waits until the environment reports that it is ready.

Use the right tool for the deployment

Jenkins itself should not contain deep deployment logic. It calls a deployment tool that understands your platform: a container platform’s own commands, a package manager for the cluster, an infrastructure tool, or a configuration tool. The tool describes the desired state of the environment, and the pipeline runs it with the right parameters. This keeps the pipeline short and the deployment logic reusable and testable outside Jenkins.

Make it idempotent

An operation is idempotent if running it twice has the same effect as running it once. Deployment steps that describe the desired end state, rather than a list of actions, are naturally idempotent. This matters, because a pipeline may fail halfway and be run again, or a retry may repeat a step. Ask of every step: “What happens if this runs twice?”

Do not touch the live side

Give the deploy step credentials that can change the idle environment only, if the platform allows it. Then even a bug in the pipeline cannot damage the live side. Separate the permission to deploy from the permission to switch.

Start clean

The idle environment may still contain the previous release’s leftovers from two releases ago. Either replace it entirely, or make sure the deployment overwrites everything it should. An idle environment that has drifted from the live one defeats the promise of parity.

The idle environment is a free testing ground. Use it to prove that the release works before any user sees it.

Health checks

A health check is a tiny automatic question: “are you alive and ready?” The application answers with a simple yes or no, possibly after checking its own connections to the database and other services. Platforms and routers use health checks to decide whether an environment may receive traffic. The pipeline uses them to wait until the new environment has started.

Waiting for readiness

A new environment takes time to start. The pipeline must wait, but not forever. Jenkins offers the waitUntil step, which repeats a check until it succeeds, with growing pauses, and the timeout step, which sets a firm limit. Together they say: “Keep asking whether green is healthy, for up to ten minutes, and fail if it never is.” Retrying such a read-only check is safe, because asking twice changes nothing.

Smoke tests

A smoke test is a short set of checks of the most important functions. The name comes from electronics: switch it on and see whether smoke comes out. Typical smoke tests include logging in, loading the home page, searching, and completing a small, harmless transaction. They run against the idle environment through a private address.

What to test on the idle side

Be careful with real data

The idle environment usually shares the live database. Smoke tests that create records will create them in production data. Use clearly marked test accounts, keep test actions small and harmless, and clean up afterwards. Never run destructive tests, such as deleting data or heavy load tests, against a shared production database.

Many teams want a person to confirm a production switch. Jenkins supports this, but the way you write it matters for cost and capacity.

The input step

The input step pauses a pipeline and asks for a decision. It can limit who may answer by user or group, which lets you insist that only release managers may approve. It can also collect a short message or a choice. The pipeline continues only after somebody approves, or fails if someone declines or the wait times out.

Do not hold an executor while waiting

A pipeline that waits for approval inside an agent block holds an executor the whole time. A release that waits overnight for a manager occupies a build slot all night, and if many releases do this, the build queue grows for everyone else. Place the approval outside any agent block, so the pipeline waits on a lightweight slot that does not consume a normal executor, and take an agent again when the release resumes.

What a good approval shows

• The version and the change summary or a link to it.
• The results of the tests and smoke checks on the idle environment.
• Which colour will become live, and which one is live now.
• A link to the dashboards to watch after the switch.
• A clear time limit, after which the release is cancelled rather than left hanging.

When automation is enough

The switch is short, but it deserves the most care of any step.

Before the switch

• Confirm that the idle environment is still healthy right now, not only ten minutes ago.
• Warm up caches and connection pools if the application needs it.
• Check that background workers and schedules are ready to move.
• Make sure the rollback path works: the old environment is healthy and untouched.
• Take a lock so that no other pipeline changes the router at the same time.

Options for the cutover

Connection draining

Requests already in progress on the old environment should be allowed to finish. The router stops sending new requests to the old side but keeps existing connections open for a short time, often thirty seconds to a few minutes. Without draining, users in the middle of a payment or an upload may see an error at the moment of the switch.

Make the switch itself idempotent

A switch step that says “send traffic to green” is safe to run twice. A switch step that says “flip to the other colour” is not: run twice, it flips back. Always state the desired end state explicitly, so a retry or a re-run cannot accidentally reverse the release.

Verify immediately

Right after the switch, the pipeline runs a few checks against the public address, not the private one: does the home page load, does login work, and are the error rates normal? If anything fails within the first minutes, the pipeline switches back automatically or alerts a person who can.

The reason many teams adopt blue-green deployment is the speed and calm of rollback.

What rollback means here

Because the old environment is still running the old version, rollback is simply another traffic switch, in the opposite direction. There is no rebuild, no redeployment, and no waiting for servers to start. It can take seconds. The old version returns to service exactly as it was, with its caches still warm and its configuration untouched.

flowchart TD
    A["Pipeline starts release"] --> B["Build once and publish artifact"]
    B --> C["Detect live colour and choose idle target"]
    C --> D["Deploy to idle and run smoke tests"]
    D -->|"Fail"| X["Stop release, live side untouched"]
    D -->|"Pass"| E["Approval without holding an agent"]
    E -->|"Declined or timed out"| X
    E -->|"Approved"| F["Switch traffic to new colour"]
    F --> G["Watch metrics and run live checks"]
    G -->|"Healthy"| H["Mark success and keep old side for rollback window"]
    G -->|"Unhealthy"| R["Switch back to old colour"]
    R --> S["Investigate while users are safe"]
    H --> T["After window: scale down or reuse old side"]

When to roll back

Manual and automatic rollback

Some teams roll back automatically when monitoring shows that the new version crosses a clear threshold. Others require a person to decide. Automatic rollback is fast but needs reliable, well-tuned signals, so that a harmless blip does not reverse a good release. Whichever you choose, provide a manual rollback job that anyone on call can run without help.

The limits of rollback

• Data changes: rolling back the application does not undo data that the new version wrote. This is why compatible data changes matter.
• External effects: emails sent and payments made by the new version cannot be unsent.
• Old side must still exist: once the old environment is scaled down or reused, rollback again requires a deployment.

The release is not finished at the switch. The old environment is an asset for a limited time, and then a cost.

The rollback window

Keep the old environment running, untouched, for a period that matches your risk. Some problems appear only after hours or days, such as a monthly report that fails, or a slow memory leak. A typical window is between a few hours and a couple of days. Shorter windows save money. Longer ones give more safety.

What to do with the old environment

Cleanup jobs

A separate scheduled Jenkins job can retire old environments after the window ends: check that no rollback was requested, scale down or remove the old side, and record the action. Keeping cleanup separate from the release keeps the release pipeline short and lets the window be set by policy.

Reuse as the next idle side

The old live environment becomes the idle target of the next release. Before reuse, make sure it is brought back into line with the live one: same infrastructure, same configuration, updated tools. A neglected idle environment slowly drifts from production, and the next release finds surprises there.

Costs to watch

A release pipeline is a sensitive job. Small Jenkins features keep it from being started wrongly or twice.

Parameters for controlled choices

Jenkins parameters are inputs supplied when a run starts. A release job commonly has a few: the artifact version to deploy, and the action to perform, such as deploy and switch, deploy only, switch only, or rollback. Use choices and checkboxes instead of free text where you can, validate every value in the first stage, and default to the safe option. Do not offer a parameter for the colour, because the pipeline should discover it.

Only one release at a time

Two releases running together against the same router would be chaos: two pipelines might both decide green is idle and overwrite each other. Use the disableConcurrentBuilds option so a second run waits or fails, and use a lock, such as one from the Lockable Resources plugin, named after the application. The lock ensures that only one pipeline may change the environments and the router at a time.

Order matters

If two releases are queued, you usually want the newest to win, not the oldest. Milestone steps can cancel older runs when a newer one arrives. But be careful: never cancel a release that has already switched traffic, because it may leave things half-done. Place milestones before the risky steps.

Who may run it

Use the right agents

Release jobs hold powerful credentials. Run them on a dedicated pool of agents with their own label, so ordinary builds and untrusted pull request builds can never share those machines. This also protects the release from a busy build queue, because releases have their own capacity.

If every team writes its own blue-green pipeline, you get dozens of styles and dozens of ways to fail. A shared library gives you one good way.

The problem with scattered pipelines

Without a common approach, one team checks the live colour and another assumes it. One drains connections and another does not. Some verify after the switch and some forget. When a security or safety improvement is needed, hundreds of Jenkinsfiles must be edited.

The shared library idea

A Jenkins shared library is reusable pipeline code kept in its own repository and loaded by many pipelines. It can provide a single custom step, for example a step that performs a complete blue-green release. The Jenkinsfile of each application then says only a few things: the application name, the artifact version, the health check address, and how long to watch after the switch.

What a standard release step can do

• Discover the live colour from the router and refuse to touch it.
• Take the application lock and apply the single-run rule.
• Deploy the exact artifact to the idle environment.
• Wait for readiness with a timeout, and run the standard smoke tests.
• Request approval outside any agent, with a standard message.
• Switch traffic with draining, stating the end state explicitly.
• Watch metrics for a period and roll back on defined thresholds.
• Write clear log lines and send standard notifications.
• Record the deployment for auditing.

Design guidelines

Whoever can flip the switch controls what every user sees. Treat that power with the seriousness it deserves.

What is at risk

A release pipeline holds credentials that can deploy software and change routing. An attacker who takes over the pipeline can ship malicious code to production, redirect traffic, or take the service down. A careless person can do similar harm by accident.

Defences

Protect the idle environment

The idle environment is a full copy of production, often with production data behind it. It must not be open to the public just because it is idle. Give it a private test address, restrict it to the team and the pipeline, and apply the same security controls as the live side. An unguarded idle twin is an easy target.

Separation of duties

In regulated settings, the person who writes a change should not be the only person who releases it. Use approvals by a different person, with the approval recorded. Jenkins can restrict who may answer an approval prompt and can write the decision to the log.

Least privilege in the platform

Give the pipeline’s platform identity only the rights it needs: change the router entry for this application, deploy to these two environments, read this registry. It should not be able to delete the database, change other applications, or alter its own permissions.

The moment of cutover is one of the most demanding times for a system. Plan for it.

Capacity for both sides

For a period, you run two full environments. The new one must be able to handle the whole production load the instant the switch happens, not a fraction of it. Check that the idle environment is sized like the live one. A smaller idle side that is fine in tests may collapse under real traffic.

Warm-up

New environments have empty caches, cold connection pools, and code that has not yet been compiled by the runtime’s just-in-time optimisers. The first requests are slow. A sudden flood of cold requests can also overwhelm shared resources such as the database. Warm up before the switch by sending representative requests, preloading common data, and starting with a gradual shift when possible.

Pressure on shared services

Both environments share the database and other backends. During the release, migrations, cache filling, and health checks add load. Avoid heavy migrations during peak hours, and run them in small batches. Watch the database’s connection count, since two environments may each hold a full pool of connections.

Scaling rules

Pipeline performance

The release pipeline itself should be quick, because the sooner the switch happens, the sooner the team can watch the result. Deploy in parallel where independent, cache dependencies, and keep smoke tests short. A release that takes three hours discourages frequent releases.

Blue-green deployment improves availability during releases, but it introduces its own single points of failure.

What it improves

• No downtime for deployments, because the live side is never touched.
• Fast recovery from bad releases, through an immediate switch back.
• Less pressure during releases, which reduces human error.

What it does not protect against

• Failures unrelated to releases, such as a broken database or a cloud outage.
• Bad data written by the new version, which rollback does not undo.
• Failure of the switch itself, such as an overloaded or misconfigured router.

The router as a critical component

Everything depends on the router. It must be highly available: run it redundantly, monitor it, and protect its configuration. Changes to it should be as reviewed as code. A mistake in the router’s configuration can send all traffic nowhere.

When the pipeline itself fails

Multiple regions

Larger systems run in several regions or zones. Releasing region by region, one after another, limits the blast radius. If the first region shows trouble, the release stops before it reaches the others. Blue-green within each region gives fast rollback locally.

The switch is only safe if you can see what happens after it. Monitoring is the pilot’s window of the release.

What to watch after the switch

Compare blue and green

The best evidence comes from comparison. Tag every metric and log line with the environment colour and the application version. Then you can put the two sides next to each other: error rates on the new side against the old side’s baseline. A jump that appears only on the new colour points straight at the release.

Business signals

Technical health is not enough. Watch the numbers that matter to the business: sign-ups, orders, payments completed, search results clicked. A release that passes every technical check but halves the number of completed orders has still failed.

Delivery metrics

Beyond a single release, track how the whole delivery process performs. Widely used measures, often grouped as the four key metrics of software delivery, are how often you deploy, how long a change takes to reach production, how often releases cause failures, and how quickly you recover. Blue-green deployment should improve all four over time.

Alerts and thresholds

Logs for the release itself

Keep the pipeline’s own log clear and complete: the live colour, the version, checks, approvals, the switch result, and the watch period. Send notifications to the team’s chat at each key moment, so everyone knows what is happening.

A release process is software too. Test it, especially the parts that only run on bad days.

What to rehearse

Test the compatibility

The single most valuable automated test for blue-green deployment is one that runs the old application version and the new one against the same database at the same time, and checks that both work. If both pass, rollback is safe at the data level.

Game days

Once or twice a year, hold a rehearsal in which you practise an incident: a bad release that must be rolled back, or a router that fails. Time the response. Gaps in alerts, permissions, and documentation appear quickly.

Keep the test setup real enough

A test router and small test environments built from the same infrastructure code as production give realistic results. A completely different setup will hide problems. Reuse the same pipeline code, with different settings.

The promise of blue-green deployment depends on the two environments being twins. Code is what keeps them that way.

The parity problem

If blue and green are set up by hand, they drift apart. One gets a patched operating system, the other a forgotten manual change. The release then behaves differently on each side, and the tests on the idle environment tell you less about what will happen on the live one.

Infrastructure as code

Infrastructure as code means describing servers, networks, and platform settings in text files kept in a repository, and creating them with automated tools. Both colours are created from the same description, so they cannot drift, and any change is reviewed. The Jenkins pipeline itself can run these tools, or a separate pipeline can keep environments up to date.

What must match

Containers and Kubernetes

On a container platform, blue and green can be two sets of pods in the same cluster, labelled with the colour. A service definition points at one label, and the switch changes the label it selects. The pipeline updates the deployment for the idle colour, waits for its pods to be ready, and then changes the service. Because both sets use the same cluster settings, parity comes almost for free.

Jenkins as code too

The Jenkins controller, its agents, and its jobs should also be described in code, for example with the Jenkins Configuration as Code plugin and Jenkinsfiles in repositories. A release system that cannot be rebuilt from files is a fragile foundation.

Blue-green deployment is a powerful technique, and it costs something.

Balancing choices

Is it worth it?

For a small internal tool that nobody uses at night, a simple restart may be enough. For a service that earns money every minute, or that many teams depend on, the cost of a second environment is small compared with the cost of downtime. There is no universal answer. Compare the cost of the extra environment with the cost of an outage and of a slow, frightening rollback.

A pattern is a solution many teams discovered independently. An anti-pattern is a trap many teams fell into.

Patterns worth copying

Anti-patterns to avoid

These lessons are usually learned the hard way. You can learn them the easy way.

Best practices

• Query the router for the live colour, and refuse to deploy to it.
• Build once and deploy an exact, immutable version everywhere.
• Make every database change backward compatible, and contract in a later release.
• Test the idle side with health checks and smoke tests through a private address.
• Put approvals outside agent blocks, with named approvers and a time limit.
• State the end state of the switch, drain connections, and verify immediately.
• Agree rollback thresholds in advance, and keep a manual rollback job ready.
• Keep the old side for a rollback window, then retire or refresh it.
• Use a lock and single-run rule so only one release changes the router at a time.
• Create both environments from code, and give release jobs their own agents.
• Tag metrics and logs with colour and version, and compare the two sides.
• Rehearse releases and rollbacks regularly.

Common mistakes and their fixes

Let us walk through a complete introduction for a fictional company, step by step, without writing any code.

The situation

Fernhill Books runs an online shop as a web application with a shared database. Releases happen every second Thursday at ten at night, using an in-place update that takes the shop offline for twenty minutes. Twice last year, a release failed and the shop stayed down for over an hour. The team wants to release during the day, without downtime, and to undo mistakes in minutes.

Step by step

The result after three months

Most teams do not start with blue-green. They arrive at it after living with the pain of in-place releases. Here is a calm way to move.

What you may find

• A single production environment updated by copying files or running a script by hand.
• A test environment that differs greatly from production.
• Database changes applied manually, sometimes with no record.
• Servers that were changed by hand over the years, nobody quite sure how.
• Release notes and steps that live in one person’s head.

A safe migration path

The reward

After migration, releases become routine events. The team gains the confidence to release small changes often, and the fear that once surrounded deployment day fades.

A release process decays if nobody owns it. Clear roles and written agreements keep it healthy.

Who owns what

Agreements to write down

• The data rule: every migration works with both versions, and destructive changes wait.
• The rollback rule: thresholds, who decides, and how long the window is.
• The approval rule: who may approve which releases, and when automatic switching is allowed.
• The parity rule: both environments come from the same code, and the idle side is refreshed before each release.
• The freeze rule: periods when production switches are not allowed, such as peak sales days.

Regular reviews

After every release that needed a rollback, hold a short, blame-free review: what happened, what signal caught it, how long did it take, and what will change. Once a quarter, review the whole process: window lengths, costs, rehearsal results, and near misses.

These scenarios show how organisations use blue-green deployment. They are illustrative, so you can map them to your own situation.

What these examples share

In every good outcome, the team treated the release as a process with rules: compatible data, private testing, an explicit switch, watched metrics, and a practised rollback. In the bad outcomes, one of these was missing, usually the data rule or the watching.

The blue-green idea is independent of any single tool. Comparing platforms shows what is essential.

Features change quickly, so check each tool’s current documentation before relying on this table.

What Jenkins does differently

Jenkins is a general orchestrator. It does not itself contain a blue-green feature; it runs your steps in order, with approvals, locks, and credentials. Many teams pair it with a specialised delivery tool that manages the traffic shifting and rollback logic, while Jenkins builds, tests, and starts the release.

What is universal

The lessons apply everywhere: build once, keep a twin environment, test privately, make data changes compatible, switch explicitly, watch agreed metrics, keep the old side for a window, and rehearse rollback.

Once the basics feel comfortable, these ideas help larger and more demanding teams.

Gradual traffic shifting

Instead of moving all users at once, shift traffic in stages, watching metrics between steps. This blends blue-green with canary ideas: the new side gets five percent, then twenty-five, then everything. If a problem appears early, only a few users are affected.

Feature flags

Feature flags separate deploying code from turning on features. Code goes live with the feature off, and product teams enable it for chosen users when ready. Combined with blue-green, they let you switch infrastructure safely and reveal features gradually, with two independent safety nets.

Automated analysis and rollback

Advanced setups compare the new side’s metrics with the old side’s automatically, using statistical checks, and roll back without human help when the new side is worse. This needs high-quality metrics and careful tuning, but it can make releases both faster and safer.

Shadow traffic

Copy real requests to the idle environment, without letting its answers reach users. The team can then see how the new version behaves under real traffic before switching. It needs care with side effects, such as writes and outgoing messages.

Multi-region releases

Release region by region, with pauses and checks between regions, and blue-green within each. A problem is caught in the first region, and the rest are protected.

Separate databases per colour

Some teams give each colour its own database, with replication or migration between them, to allow incompatible changes. It is powerful and difficult: data written during the rollback window must be reconciled. Consider it only when expand and contract cannot serve you.

When something feels wrong, walk through these questions in order.

Every important word from this guide in one place, explained in plain language.

Short answers to the questions people ask most.

Blue-green deployment turns a frightening release into a calm, reversible switch.

You began with a restaurant that built an identical twin next door and moved the customers by changing the sign, and finished with a full picture of how a Jenkins pipeline builds once, deploys to the idle environment, tests it privately, asks for approval, switches traffic, watches the result, and can roll back in seconds. Along the way you learned how to choose a traffic switch, why database changes must be compatible with both versions, how sessions, caches, and background jobs affect the cutover, and how locks, permissions, shared libraries, monitoring, and rehearsals keep the process safe. The main rules are simple: ask the router, build once, make data changes compatible, state the switch explicitly, watch agreed numbers, and keep the old side for a window.