DevOps Deployment Strategies

A deployment strategy is a plan for releasing a new version of an application. A good plan keeps the application available, limits the damage from bugs, and allows a quick return to the old version. Different strategies suit different risks and budgets.

Why Strategy Matters

Think of a restaurant that wants to change its menu. The owner could close the restaurant for a day, swap every dish at once, or test one new dish with a few tables. Each choice carries a different level of risk. Software teams face the same choice with every release.

Recreate

The recreate strategy stops the old version and starts the new version in its place. Users see downtime between the two steps.

 v1 v1 v1  --->  (stopped)  --->  v2 v2 v2
              downtime here

This approach is simple and cheap. Use it for internal tools and night-time maintenance windows.

Rolling Update

A rolling update replaces old copies with new copies a few at a time. The application stays online during the whole process.

 Step 1:  v1 v1 v1 v1
 Step 2:  v2 v1 v1 v1
 Step 3:  v2 v2 v1 v1
 Step 4:  v2 v2 v2 v1
 Step 5:  v2 v2 v2 v2

Kubernetes uses rolling updates by default. Both versions run side by side for a short time, so the new version must stay compatible with the old data.

Blue-Green

Blue-green keeps two identical environments. Blue serves live users while green holds the new version. After testing green, the team switches traffic from blue to green in one step.

              +--> [ Blue  - v1 ]  (idle after switch)
 Users --> Router
              +--> [ Green - v2 ]  (live after switch)

The switch happens instantly, and a rollback means pointing the router back to blue. The cost is double the infrastructure during the release.

Canary

A canary release sends a small share of users to the new version first. The name comes from canary birds that miners once carried to detect danger early.

                +--> [ v1 ]  95% of users
 Users --> Router
                +--> [ v2 ]   5% of users  (watched closely)

The team watches errors, speed, and business numbers for the canary group. Healthy results lead to a larger share in steps, such as 25, 50, and 100 percent. Bad results lead to an immediate stop.

Comparing the Strategies

Example: Rolling Update in Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: shop
  template:
    metadata:
      labels:
        app: shop
    spec:
      containers:
        - name: shop
          image: shop:2.0

The setting maxUnavailable: 1 allows at most one copy to be down at a time. The setting maxSurge: 1 allows one extra copy during the change.

Database Changes

Database changes need extra care in every strategy. Add new columns before the new code needs them, and remove old columns only after the old code is gone. This pattern lets both versions work with the same database.

Choosing the Right Strategy

• Pick recreate for small tools where short downtime is fine.
• Pick rolling for most everyday web applications.
• Pick blue-green when fast rollback matters most.
• Pick canary when the application serves many users and mistakes cost a lot.

Shadow Deployment

A shadow deployment copies live traffic to the new version while users still receive answers from the old version. The new version processes the copy and never replies to real users. Teams compare results and speed against the old version. Shadow runs reveal bugs and performance problems without any user impact. The method suits large changes, such as a rewritten search engine.

 Users --> Router --> [ v1 ] --> Reply to user
                |
                +----> [ v2 ] --> Results compared, no reply

A/B Testing

A/B testing is a business experiment, not a safety check. The router sends group A to one design and group B to another. The team measures a goal such as sign-ups and keeps the winner. Canary releases ask whether a version is safe. A/B tests ask whether a version is better.

Progressive Delivery

Progressive delivery automates canary steps. Tools such as Argo Rollouts and Flagger raise traffic in stages and read metrics after each stage. A healthy result moves the rollout forward. An unhealthy result triggers an automatic rollback.

strategy:
  canary:
    steps:
      - setWeight: 10
      - pause: { duration: 10m }
      - setWeight: 50
      - pause: { duration: 10m }

The plan sends 10 percent of traffic to the new version for ten minutes and raises the share to 50 percent for another ten minutes. The remaining traffic moves over when no alarm fires.

Rollback Triggers

Define the rollback rules before the release starts. Clear rules remove arguments during a stressful moment. Common triggers include:

• Error rate above an agreed limit, such as 2 percent.
• Response time above the normal range for five minutes.
• Failed health checks on new copies.
• A sudden drop in orders or sign-ups.

Release Checklist

• Confirm that dashboards and alerts cover the new version.
• Confirm that the previous version stays available for rollback.
• Run database changes in a backward-compatible way.
• Name one person who owns the release decision.

Key Points

• Each strategy balances downtime, cost, and risk differently.
• Monitoring data decides whether a release continues or stops.
• A tested rollback plan belongs in every release.