Gnu Group Learning AcademyGnu Group ↗
CI/CD Fundamentals · Module 10 of 12

Deployment strategies, health and rollback

Use verifiable deployment steps, health checks and a tested rollback path instead of treating a successful command exit as proof of service health.

Learning objectives

By the end of this module, you should be able to:

  • Distinguish deployment completion from application readiness.
  • Compare rolling, blue/green and canary concepts.
  • Design rollback around an immutable previous release.

A successful deploy command is not enough

The deployment system may report success while the application is unhealthy. Post-deployment verification should exercise the service or its readiness signal before promotion is considered complete.

Strategies manage change exposure

Rolling replaces capacity incrementally, blue/green switches between two environments, and canary exposes a new version to a limited share before broader rollout. Each needs monitoring and rollback criteria.

Rollback needs a known-good artifact

Record the previously deployed immutable artifact identity and keep a tested path to restore it. Rollback should not depend on reconstructing an old build from memory.

Worked examples

See the idea in practice.

Deploy then verify

deploy artifact-42
curl -fsS https://service.example/health
# only then record promotion success
  • Deployment state and service health are separate checks.
  • A failed health check should trigger investigation or rollback according to policy.
Hands-on lab

Lab — Deploy, health-check and rollback locally

Goal: Simulate atomic release switching and restore the previous release after a failed health check.

STEP 1

Create two releases

mkdir -p ~/gnu-cicd-labs/module10/releases/{v1,v2} && cd ~/gnu-cicd-labs/module10
printf 'status=healthy\nversion=v1\n' > releases/v1/health.txt
printf 'status=broken\nversion=v2\n' > releases/v2/health.txt
STEP 2

Deploy known-good

ln -sfn releases/v1 current
grep -q 'status=healthy' current/health.txt
STEP 3

Attempt new deployment

PREVIOUS=$(readlink current)
ln -sfn releases/v2 current
if ! grep -q 'status=healthy' current/health.txt; then ln -sfn "$PREVIOUS" current; fi
STEP 4

Verify rollback

grep -q 'version=v1' current/health.txt

Verify

  • The broken v2 release fails health validation.
  • The current pointer returns to v1.

Expected outcome

  • A failed post-deployment check restores the recorded prior release.

If it fails

  • Use absolute paths if symbolic-link behavior differs in your shell environment.
  • Real systems should define explicit health thresholds and avoid endless automated rollback loops.
Real-world connection

Release safety depends on detecting bad behavior after deployment and having a deterministic path back.

Avoid these traps

Common mistakes

  • Equating a successful deployment command with application health.
  • Rolling back by rebuilding an old version.
  • Using canary/blue-green terminology without measurable promotion and rollback criteria.
Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What should follow a deployment command?

A service/readiness verification appropriate to the application before declaring success.

2What does a canary strategy limit?

Initial exposure of the new version so evidence can be gathered before broader rollout.

3What is the safest rollback input?

The recorded immutable identity of the previous known-good artifact.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.