Blue-Green Deployment — Database Migration Rollback Traps

Every deployment is a calculated gamble. You're shipping untested code into a live system that real users depend on right now. The traditional approach — stop the app, deploy, restart, pray — trades availability for simplicity. At small scale that's fine. At production scale, that maintenance window is a revenue event, a support ticket storm, and a trust problem all at once. Companies like Amazon measured that every 100ms of latency costs them 1% in sales. Downtime isn't measured in minutes; it's measured in dollars and reputation.

Blue-green deployment solves the deployment risk problem at its root. Instead of mutating your live environment in place, you build a complete, parallel environment — run every health check and smoke test against it while real traffic still hits the original — then switch. The switch is a routing change, not a deployment. That distinction is everything. Your rollback is equally trivial: re-route traffic back. No re-deploys, no frantic hotfixes at 2am, no partial states.

By the end of this article you'll understand the full internal mechanics of blue-green deployments including DNS vs load-balancer vs service-mesh switching strategies, the database migration problem that trips up most teams, how to wire this into a real CI/CD pipeline with Nginx and shell scripting, the subtle failure modes nobody talks about in blog posts, and exactly how to answer the curveball questions interviewers throw at senior candidates.

What is Blue-Green Deployment?

Blue-green deployment is a release pattern that keeps two production environments running simultaneously. Let's call them Blue (the current live) and Green (the new version). You deploy the new version to Green while all real traffic still hits Blue. Once Green passes all health checks and smoke tests, you flip the traffic router — DNS, load balancer, or service mesh — so that incoming requests go to Green. Blue stays live, idle but ready, serving as an instant rollback target.

The magic isn't in the deploy. It's in the switch. A routing change is fast, atomic, and reversible. You don't redeploy anything during rollback — you just flip the switch back. That's why blue-green pairs so well with database migrations that are backward-compatible: if the migration can't be undone, you've lost the rollback benefit.

# TheCodeForge — Nginx blue-green traffic switch
upstream blue {
    server 10.0.1.10:80;  # blue environment
    server 10.0.1.11:80;
}

upstream green {
    server 10.0.2.10:80;  # green environment
    server 10.0.2.11:80;
}

server {
    listen 80;
    location / {
        # Switch this line to flip traffic: blue -> green
        proxy_pass http://green;
        # For rollback, change to http://blue
    }
}

Blue-Green Deployment Flow Diagram

The core blue-green workflow consists of five distinct phases: deploy to idle environment, verify the new environment, switch traffic, monitor for issues, and optionally rollback. The diagram below shows the flow from start to finish, including the rollback path. This mental model helps teams understand where automation and human intervention fit.

Deployment Strategies Comparison: Rolling Update vs Blue-Green vs Canary Release

Three major zero-downtime deployment strategies exist, each with a different trade-off between rollback speed, infrastructure cost, and complexity.

Rolling Update: Instances are replaced one by one (or batch by batch). The old version runs alongside the new during the transition. Rollback requires redeploying the old version across all instances, which can take minutes. Infrastructure cost is minimal (no duplicate environment). Best for stateless apps with simple rollback needs.

Blue-Green: Two identical environments. Rollback is a routing change measured in seconds. Infrastructure cost doubles while both environments run together. Best for critical services where a 30-second outage costs more than running spare instances.

Canary Release: New version starts with a small traffic percentage (e.g., 5%) and gradually increases to 100%. Rollback means reducing the percentage back to zero. Infrastructure cost is close to single-environment (canary instances can be small). Best for high-risk changes where you want real-user validation before full exposure.

Below is a side-by-side comparison for quick reference:

| Strategy       | Rollback Time | Infrastructure Cost | Database Migration Support | Traffic Control Granularity |
|----------------|---------------|---------------------|----------------------------|-----------------------------|
| Rolling Update | Minutes       | 1x (sequential)     | Limited by per-instance order | Per node                      |
| Blue-Green     | Seconds       | 2x                  | Expand-contract required    | Binary (100% one environment) |
| Canary Release | Minutes       | 1x + small fraction | Same as blue-green         | Gradual (1% to 100%)          |

Traffic Switching Mechanisms: DNS, Load Balancer, and Service Mesh

The switch is the core of blue-green. Three common mechanisms exist, each with different properties.

DNS-based switching: You update a DNS record (e.g., change A record from blue LB IP to green LB IP). Simple, no extra infrastructure. But DNS propagation takes minutes to hours depending on TTL — not atomic. For a clean cutover, you must set TTL to a low value (60s) at least 24 hours in advance. During propagation, some users hit blue, some hit green. If your service can't handle dual versions for a few minutes, this isn't for you.

Load balancer switching: Your LB has target groups for blue and green. You swap the active target group. This is near-instant (seconds). The LB handles health checks and connection draining. Most production systems use this — AWS ALB, Nginx upstream, HAProxy. The catch: the LB is a single point of failure if not redundant.

Service mesh switching: Tools like Istio or Consul use traffic routing rules to shift percentages. You can do canary within blue-green — route 10% to green, observe, then shift 100%. This gives the best observability but adds complexity to the mesh control plane.

#!/bin/bash
# TheCodeForge — Switch traffic from blue to green via AWS ALB
# Usage: ./switch-blue-green.sh prod

ENV="$1"
BLUE_TG="arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/blue-${ENV}/abc123"
GREEN_TG="arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/green-${ENV}/def456"
ALB_ARN="arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/${ENV}-alb/xyz789"

echo "Switching ${ENV} traffic from blue to green..."

# Retrieve current listener rule
LISTENER_RULE=$(aws elbv2 describe-rules \
  --listener-arn "arn:aws:elasticloadbalancing:us-east-1:123456789012:listener/app/${ENV}-alb/xyz789/abc123" \
  --query 'Rules[?Priority==`1`].Actions[0].ForwardConfig.TargetGroups' \
  --output text)

echo "Current target group: $LISTENER_RULE"

# Update the default rule to forward to green
aws elbv2 modify-rule \
  --rule-arn "arn:aws:elasticloadbalancing:us-east-1:123456789012:listener-rule/app/${ENV}-alb/xyz789/abc123/def456" \
  --actions "Type=forward,ForwardConfig={TargetGroups=[{TargetGroupArn=${GREEN_TG}}]}"

echo "Switch complete. Traffic now goes to green."

The Database Migration Problem

Blue-green deployment is straightforward when your release only changes application code. But when you need database schema changes — adding a column, renaming a table, changing a constraint — you face a dilemma.

The problem: both environments (blue and green) access the same database. When you deploy green with new code expecting a new column, but the database hasn't been migrated yet, green crashes. If you migrate the database before the switch, blue (still live) breaks because its code can't handle the new schema.

The solution: expand-contract pattern. Every schema change must be backward-compatible. That means: - Add new columns as nullable or with default values. - Never rename or drop columns in the same release that changes code. - Use three-phase deployment: 1) deploy migration to add new schema (nullable, no code changes), 2) deploy new code that uses both old and new schema, 3) after all traffic is on new code, deploy cleanup migration to remove old columns.

Tools like Flyway or Liquibase help version migrations and enforce order. But the real discipline is the team agreeing on backward-compatibility as a non-negotiable rule.

-- TheCodeForge — Expand-Contract Migration Example

-- Phase 1: Expand (add new column, backward-compatible)
ALTER TABLE orders ADD COLUMN new_status VARCHAR(20) NULL;
-- Old code sees 'status' only, new code sees both.

-- Phase 2: Deploy new code that writes to both 'status' and 'new_status'
-- After switch, both environments can read/write.

-- Phase 3: Contract (after green is live and blue is decommissioned)
ALTER TABLE orders DROP COLUMN status;
ALTER TABLE orders RENAME COLUMN new_status TO status;

CI/CD Pipeline for Blue-Green with Nginx and Shell Scripts

A production-grade blue-green pipeline needs automation. Here's a practical example using a CI/CD tool, Nginx as a soft switch (via upstream config reload), and idempotent shell scripts.

The pipeline: 1. Build and test your application. 2. Deploy to the idle environment (say, green). The deployment script checks which environment is live by querying a file or health check endpoint. 3. Run smoke tests against the new environment directly (internal load balancer, not public). 4. If tests pass, run the Nginx config reload script to switch traffic from blue to green. 5. Monitor for 10 minutes. If errors exceed threshold, run rollback script (reload with blue upstream). 6. If stable, decommission the old environment (optional: keep warm for rollback).

The key script: a switch script that modifies /etc/nginx/conf.d/blue-green.conf and reloads Nginx gracefully (nginx -s reload). The rollback script does the same but reverts.

Idempotency is crucial: running the switch script twice should not cause errors. Track the current active environment in a simple file: /var/run/active-env.txt. The script reads this file before switching.

#!/bin/bash
# TheCodeForge — Automated blue-green deploy
set -euo pipefail

ENV="${1:-staging}"
APP_VERSION="${2:-latest}"

# Determine current active environment
if grep -q 'green' /var/run/active-env.txt; then
  TARGET="blue"
  CURRENT="green"
else
  TARGET="green"
  CURRENT="blue"
fi

echo "Deploying ${APP_VERSION} to ${TARGET} (${ENV})..."

# Deploy to target environment (docker-compose or kubernetes)
docker compose -f "docker-compose.${ENV}.yml" -p "${TARGET}" up -d --pull always

echo "Waiting for health check..."
sleep 10
curl --fail http://${TARGET}.internal.example.com/health || exit 1

echo "Switching traffic from ${CURRENT} to ${TARGET}..."
sed -i "s/proxy_pass http:\/\/${CURRENT}/proxy_pass http:\/\/${TARGET}/" /etc/nginx/conf.d/blue-green.conf
nginx -s reload

echo "${TARGET}" > /var/run/active-env.txt
echo "Deploy successful. Active environment: ${TARGET}"

Failure Modes and Rollback Realities

Blue-green deployment promises instant rollback, but there are subtle failure modes that break that promise.

Failure 1: Environment mismatch. The green environment was deployed with a newer config (e.g., different database host, different API keys) that doesn't match the infrastructure of blue. When you rollback, blue may not work because its dependencies changed.

Failure 2: Data divergence. During the time green was live, users modified the database. The blue environment, when switched back, sees data that its code cannot handle (e.g., new column populated). Rollback becomes data repair, not instant.

Failure 3: Partial switch. If you use feature flags or gradual traffic routing, only part of the traffic switched. Rolling back means identifying exactly which users saw the new version and ensuring their session state is consistent.

Failure 4: Warmup landmines. Green passes health checks but fails because JIT compilation or connection pools weren't warm. Real load exposes these. Canary within blue-green (send 5% traffic to green first) catches this.

Mitigation: Use a gradual blue-green approach — switch 10% traffic, observe, then 100%. This gives you a real feedback loop before committing all users.

#!/bin/bash
# TheCodeForge — Gradual blue-green traffic shift with HAProxy

# Initial config: 100% blue, 0% green
# Change weight to shift gradually

for pct in 10 25 50 75 100; do
  echo "Setting green weight to ${pct}%..."
  sed -i "s/server green weight [0-9]*/server green weight ${pct}/" /etc/haproxy/haproxy.cfg
  haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)
  sleep 60  # Observe metrics
  if grep -q "ERROR_RATE_THRESHOLD" /var/log/haproxy/errors.log; then
    echo "Error rate exceeded! Rolling back..."
    # Revert to 0% green
    sed -i 's/server green weight [0-9]*/server green weight 0/' /etc/haproxy/haproxy.cfg
    exit 1
  fi
done
echo "Gradual switch complete. 100% green."

Observability and Monitoring During Blue-Green

You can't trust a switch you can't observe. During a blue-green deployment, you need real-time visibility into both environments.

For tracing: use distributed tracing (Jaeger, Zipkin) to compare request paths. A new version might call different downstream services or have different timeouts.

Alerting: set up a 'deployment window' alert that triggers if error rate exceeds 0.5% for 1 minute after switch. This alert should be separate from your regular alerts — allow a brief grace period to avoid false positives.

Observability also means logging the switch itself. Log every switch attempt, success/failure, and rollback. This helps post-mortems.

# TheCodeForge — Prometheus recording rules for blue-green
# Use these to alert on deployment anomalies

groups:
  - name: blue-green
    rules:
      - record: job:error_rate:ratio1m
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[1m]))
          /
          sum(rate(http_requests_total[1m]))
      - alert: BlueGreenErrorBurst
        expr: job:error_rate:ratio1m > 0.005
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Blue-green switch may have caused error burst"
          description: "Error rate {{ $value | humanizePercentage }} for job {{ $labels.job }}"

When NOT to Use Blue-Green Deployment

Blue-green is powerful, but it is not the right choice for every scenario. Applying it in the wrong context can introduce unnecessary complexity and risk without giving you the expected benefits.

1. Stateful services with non-backward-compatible data changes. If your database migration cannot be made backward-compatible (e.g., renaming a column that thousands of lines of legacy code depend on), blue-green's rollback guarantee collapses. The old environment cannot serve traffic with the new schema. In this case, a feature flag approach or a maintenance window is safer.

2. High infrastructure cost sensitivity. Running two full production environments doubles your compute costs. If your infrastructure budget is tight, consider rolling updates or canary releases. Some teams try to save by scaling down the idle environment, but that risks rollback readiness because the idle environment may not handle full traffic load instantly.

3. Static or mostly-static websites. Deploying a static site via blue-green is overkill. A simple rolling update with a CDN cache purge is faster and cheaper. Blue-green adds operational complexity for no benefit when the app has no database or state.

4. Small teams without deployment automation expertise. Blue-green requires CI/CD automation, health check wiring, and disciplined rollback scripts. A small team might struggle to maintain the pipeline and end up debugging deployment issues rather than shipping features. Start with a simpler strategy and migrate to blue-green as the team grows.

5. Applications with long-lived transactions or heavy websocket state. Draining connections during a switch can be problematic. If your service holds significant in-memory session state (e.g., multiplayer game server), a blue-green switch may drop those sessions. Consider session persistence at the load balancer or using a distributed cache.

Key Benefits: Why You’ll Sleep Better at Night

Blue-green isn't just buzzword bingo. It’s a tactical play that buys you three things: near-zero downtime, instant rollbacks, and the ability to test in production without nuking your users.

Near-zero downtime is obvious. You switch traffic, not servers. The old environment stays hot until you’re confident the new one isn’t on fire. Easy rollbacks are the real killer feature. When the new release corrupts data or spikes latency, you flip the switch back. No git revert, no rebuild, no 2 a.m. post-mortem. You’re back in seconds.

Safe testing in production lets you validate against real traffic, real databases, real chaos — without exposing every user to your bug. Pair it with a service mesh or feature flags, and you’ve got A/B testing for free. Business continuity isn’t a slide deck anymore. It’s a toggle.

Senior Shortcut: The rollback speed is the metric. If you can't go from green to blue in under 30 seconds, you’ve overcomplicated your infrastructure.

// io.thecodeforge — devops tutorial

# Trigger rollback via load balancer config change
apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-bluegreen-config
data:
  upstream backend {
    server blue-cluster:8080 weight=100;  # live
    server green-cluster:8080 weight=0;   # drain
  }

  # On rollback: swap weights
  # upstream backend {
  #   server blue-cluster:8080 weight=0;
  #   server green-cluster:8080 weight=100;
  # }

Core Architecture: Two Pockets, One Wallet

Blue-green deployment is stupid simple. Two identical production environments. Call them blue and green. At any time, one is live (blue), the other is idle (green). You deploy the new version to the idle environment. You smoke-test it. Then you flip traffic.

But here’s the part most tutorials skip: the environments must be stateless replicas. Same DB schema, same caching layer, same DNS records — or they aren't interchangeable. If your green environment talks to a different database, you’ve built a staging environment, not a blue-green deployment.

The traffic switch is a load balancer config change, DNS TTL manipulation, or service mesh routing rule. Do not rebuild the world. Do not re-provision. Flip the switch.

In practice, the idle environment stays hot for hours after the switch. You keep it as a fallback. Only after you’ve verified logs, metrics, and user reports, you tear down the old one. And you always keep one environment warm for the next deploy.

// io.thecodeforge — devops tutorial

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend-blue
spec:
  replicas: 5
  selector:
    matchLabels:
      app: frontend
      env: blue
  template:
    metadata:
      labels:
        app: frontend
        env: blue
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend-green
spec:
  replicas: 5
  selector:
    matchLabels:
      app: frontend
      env: green
  template:
    metadata:
      labels:
        app: frontend
        env: green
    spec:
      containers:
      - name: nginx
        image: nginx:1.26
        ports:
        - containerPort: 80

Kubernetes Orchestration: Why You Kill the Old Pods Last

Kubernetes doesn't give you blue-green for free. It gives you Deployments with rolling updates, and you have to fight it to get a true cut-over. The trick: run two Deployments side by side, each with a unique label like version: blue or version: green. Point your Service at the active version's label selector. When you're ready to switch, update the Service's selector, then kill the old ReplicaSet. That's not a kubectl apply — that's a manual or pipeline-driven toggling of traffic.

Do not rely on Ingress controllers for this unless you're using something like Istio or Contour with weighted routing. The vanilla Ingress NGINX can't split traffic per pod label. You need a Service Mesh or multi-IP DNS entries. Otherwise, your 'cut-over' is a DNS TTL race condition that will haunt you at 3 AM. Use a headless Service or a multicluster ingress if you care about zero-downtime. Otherwise, you're just pretending.

// io.thecodeforge — devops tutorial

apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: myapp
    version: blue   # toggle to 'green' on switch
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
spec:
  replicas: 5
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: app
        image: myapp:1.2.3
        ports:
        - containerPort: 8080

Cost-Benefit: The Real Bill for Two Pockets of Infrastructure

Blue-green means you pay for double capacity during the cut-over window. That's not just EC2 or pod costs — it's database connections, cache warming, persistent storage snapshots. If you're running 50 microservices, each with 3 replicas, you're paying for 300 instances instead of 150. The benefit? Zero-downtime. The cost? A 2x infrastructure bill for the duration of your deployment window. For a 10-minute cut-over on a high-traffic service, that's negligible. For a weekend-long database migration with read replicas and connection pooling, that's a line item your finance team will question.

Don't do this for every service. Do it for the ones where a failed deployment costs you customers or compliance violations. For internal CRUD apps? Use a rolling update with a circuit breaker. The math: if your deployment frequency is once a week and cut-over lasts 15 minutes, your 'overhead' is 0.15% of weekly compute costs. That's noise. But if you're running spot instances that get reclaimed mid-cut, you'll pay for fallback on-demand pricing. Factor that into your TCO before you sell this to your VP.

// io.thecodeforge — devops tutorial

cost_analysis:
  service: api-gateway
  base_capacity: 10 instances @ $0.10/hr = $1.00/hr
  blue_green_overhead:
    duration: 15 minutes
    extra_instances: 10
    extra_cost: $0.025 (15 min * $0.10)
  weekly_frequency: 2 deployments
  weekly_overhead: $0.05
  yearly_overhead: $2.60
  risk_of_failure: null
  # vs. rolling update downtime cost (1 hour outage @ $5000/hr = $5000)

Organizational Readiness: The Real Prerequisite Is Discipline

Blue-green is a technical pattern that fails when your org lacks deployment hygiene. You need automated CI/CD that tags every build with a unique version. You need feature flags so you can test the green environment without exposing it. You need a cross-functional team that agrees on the cut-over window and the rollback trigger. If your team ships hotfixes directly to production, blue-green will become a 'warm green, cold blue' mess where no one knows which environment is live.

Before you spend two sprints building a blue-green pipeline, check these boxes: 1) Your staging environment is an exact production clone in terms of data size and configuration — not a toy. 2) Your team has a runbook for rolling back within 2 minutes. 3) Your monitoring tells you if green is healthy before you switch traffic. If you can't answer 'yes' to all three, you're building a house of cards. Start with a canary release on a single host. Walk before you run two identical fleets.

// io.thecodeforge — devops tutorial

readiness_audit:
  ci_cd_pipeline: automated_build_and_versioning
  staging_parity:
    data_size: production_1_to_1
    configuration_sync: true
  rollback_runbook:
    defined: true
    max_time_seconds: 120
  monitoring:
    health_check_endpoint: /healthz
    latency_alert_p95_ms: 200
  team_training:
    blue_green_drills_completed: 3
  # RED FLAG: manual hotfixes bypassing pipeline

Historical Evolution and Industry Adoption

Blue-green deployment emerged from the need to eliminate downtime during software releases. Before 2010, most teams relied on rolling updates or big-bang deployments, which either caused partial outages or required maintenance windows. The concept gained traction as continuous delivery matured, with ThoughtWorks and Netflix leading the shift. By 2015, cloud infrastructure made full environment duplication affordable, and adoption spread from SaaS giants to mid-market engineering teams. Today, blue-green is standard in high-availability systems, but adoption varies by industry: fintech and e-commerce run it aggressively; legacy enterprise often skips it due to infrastructure inertia. Understanding this history matters because the pattern only works when your organization treats environments as disposable—a cultural shift, not a technical one. If your team still fears killing old pods, you are not ready for blue-green.

// io.thecodeforge — devops tutorial

stages:
  - era: before 2010
    pattern: rolling update
    downtime: partial
  - era: 2010-2015
    pattern: blue-green pioneer
    adopters: [Netflix, Etsy, ThoughtWorks]
  - era: 2015-2020
    pattern: cloud-native standard
    adopters: [AWS, Azure, GCP]
  - era: 2020-present
    pattern: multi-cluster blue-green
    infrastructure: [Kubernetes, Service Mesh]

Platform-Specific Implementations

Blue-green deployment behaves differently across platforms. AWS uses Elastic Beanstalk environments or Route53 weighted routing to flip traffic between two ASGs. Azure leverages Deployment Slots in App Service, swapping staging to production without code changes. GCP employs Traffic Splitting on Cloud Run or multiple ReplicaSets in GKE. On Kubernetes, you create two identical Deployments behind a Service selector that you update atomically. The critical difference: managed platforms handle traffic switching for you, but restrict rollback speed and database access. Kubernetes gives full control but demands you write the orchestrator logic. Never assume a platform's built-in blue-green handles database migrations; each requires a separate sequence for schema changes. Pick your platform by your rollback tolerance, not your comfort with YAML.

// io.thecodeforge — devops tutorial

# AWS: two ASGs behind ALB target groups
blue_asg: blue-v1
green_asg: green-v2
alb_rule: weight 0 -> weight 100

# Azure: deployment slots
app_service: my-api
slots: [staging, production]
swap: immediate

# Kubernetes: two deployments, one service
apiVersion: v1
kind: Service
metadata:
  name: app-svc
spec:
  selector:
    app: my-app
    color: green

Cloud-Native Managed Services

Managed services abstract away blue-green mechanics so you focus on code, not infrastructure. AWS CodeDeploy orchestrates blue-green for EC2 and Lambda—you define an AppSpec and it handles instance creation, health checks, and traffic rerouting. Google Cloud Run's revision-based model lets you pin any revision to 100% traffic, then split or rollback in one API call. Azure DevOps Deployment Pipelines integrate with App Service slots for automated swap-and-monitor sequences. The trade-off: you lose control over the exact traffic-shifting mechanism and cost isolation between environments. Managed services charge for idle green environments unless you auto-terminate them after verification. Always configure lifecycle hooks to shut down old environments within minutes—or your cloud bill becomes a horror story.

// io.thecodeforge — devops tutorial

# AWS CodeDeploy blue/green config
blueGreenDeploymentConfiguration:
  terminateBlueInstances:
    action: TERMINATE
    terminationWaitTimeInMinutes: 5

# Cloud Run traffic split
spec:
  traffic:
    - revision: blue
      percent: 0
    - revision: green
      percent: 100

# Azure slot auto-swap
siteConfig:
  autoSwapSlotName: staging