ENGINEERING NOTE / 09
A repeatable container release workflow
A release is more than a successful Docker build. The same artifact should be testable, identifiable, deployable, and recoverable when a service behaves differently in production.
In this note 05 questions
What should CI verify?
Run the project's build and meaningful tests before publishing an image. Keep the source revision and image version linked so the running container can be traced back to a specific change.
Why tag an image by version?
A version or commit-based tag identifies the exact artifact that passed checks. A mutable latest tag is convenient for browsing, but it is a poor rollback target on its own.
Where should secrets live?
Runtime secrets belong in deployment configuration or a secret store, not in the image or repository. The application should fail clearly if required configuration is absent.
How do you know deployment succeeded?
Check more than container startup: inspect health, proxy routing, HTTPS, a representative request, and logs. A running process may still be unable to reach its database or serve the public route.
How do you roll back?
Keep the previous known-good image and its compatible configuration available. Redeploy that version, verify traffic, and investigate the failed release separately. Database changes need their own rollback plan.