Delivery approvals and rollback

Decide what the pipeline promises

Continuous integration checks shared changes. Continuous delivery keeps tested changes ready for a controlled release decision. Continuous deployment automatically releases changes meeting the configured gates. A workflow that builds an image but never selects a target has not deployed an application.

For a future dev → QA → preproduction → production flow, define what allows a release to enter each environment. Promote the identified artifact you tested, supply the intended configuration, and check the actual target. GitHub environment protection features depend on repository visibility and plan; verify availability before relying on required reviewers.

Write the decision before changing the target

A compact release record connects:

“Job succeeded” is not a substitute for the operation check. The job might have selected the wrong account, skipped deployment, or returned before the application was ready. Check the target's actual running image and behavior after the deployment command completes.

Rehearse recovery with the disposable status server

Use docker-status after the Compose fixture lab, with no other fixture using port 8765. Build the restored ok version and give it a recovery name:

docker build -t learnwithsk-status:good .
docker run --rm -d --name sk-release -p 127.0.0.1:8765:8000 learnwithsk-status:good
curl --fail --max-time 3 http://127.0.0.1:8765/status.json
docker stop sk-release

Expect the ok JSON. Change the file to {"status":"broken-fixture"}, build it as learnwithsk-status:trial, and run that tag with the same name/port options. The HTTP request still succeeds, but the body violates the intended ok condition. This models a semantic failure the health check misses, not a real MicroBank incident.

Stop the trial container, run learnwithsk-status:good again, and repeat the same body check. Restore the source file to ok. Stop the fixture and remove the two extra image tags after recording their actual image IDs. These local tags are convenient rehearsal names; registry promotion needs the immutable identity taught previously.

Understand what rollback cannot undo

Replacing the application image does not reverse every database migration, data write, or message already published. An older binary may be unable to read a newer schema. Recovery might require a compatible forward fix, a disabled feature, or a tested data restore rather than simply selecting yesterday's image.

Coordinate deployments to the same environment so incompatible changes do not overlap. Retain the previous artifact and compatible configuration for the intended recovery window. Verify asynchronous consumers and transactions, not only a landing page. A Git revert changes source; it does not itself prove a running target changed or data was restored.

Checkpoint: why did the trial HTTP command succeed? It received a valid response even though its content was wrong for our rule. Why was recovery simple here? The fixture has no database or external writes. Next, complete the test-only CI lab, then carry this reasoning into MicroBank's explicitly local delivery and transaction checks. Kubernetes rollouts and Argo CD belong to the later path.

References: continuous delivery↗, GitHub environments↗, and Docker run↗.