The goal of a good CI/CD pipeline is boring deployments: a merged change ships automatically, gets verified, and either succeeds quietly or fails loudly and safely. Docker makes the "works the same everywhere" part easier; CI/CD makes the "ships automatically and safely" part real.
Build and test stages
- Lint and type-check first — fail fast on cheap checks before running expensive ones.
- Run the automated test suite inside a container that matches production as closely as possible.
- Build the production image once, and reuse that same image through every later stage — don't rebuild per environment.
- Tag images with something traceable (a commit SHA), never just "latest," so you always know exactly what's deployed.
Environment configuration
Keep configuration out of the image entirely — inject it at runtime through environment variables or a mounted config, so the same built image can move from staging to production unchanged. If you find yourself rebuilding an image just to point it at a different database, that's a sign configuration and code are too tightly coupled.
Secrets management
- Never bake secrets into a Docker image or commit them to version control — treat this as a hard rule, not a guideline.
- Use your platform's secrets manager or a dedicated tool, injected at deploy time or runtime.
- Rotate secrets periodically, and immediately after any suspected exposure — have a known process for this before you need it urgently.
An example pipeline
on: push to main
→ install dependencies (cached)
→ lint + type-check
→ run automated tests
→ build Docker image, tag with commit SHA
→ push image to registry
→ deploy to staging, run smoke tests
→ manual or automatic promotion to production
→ deploy to production (rolling or blue-green)
→ post-deploy health checkRollback strategies
| Strategy | How it works | Good fit when |
|---|---|---|
| Rolling restart to previous tag | Redeploy the last known-good image tag. | Simple setups, fast recovery is enough. |
| Blue-green | Run old and new versions side by side, switch traffic once verified. | Zero-downtime requirements, easy instant rollback. |
| Canary | Shift a small percentage of traffic to the new version first. | High-traffic systems where a bad deploy is costly. |
Automating deployment without automated tests and a health check after deploy just means bad changes reach production faster. Verification at each stage is what actually makes the automation safe.
Deployment verification
After every deploy, run a smoke test against real endpoints and check key metrics (error rate, response time) for a few minutes before considering the deploy "done." Automate the decision to roll back when those signals look wrong, rather than relying on someone noticing manually.
Still deploying by hand, or want your pipeline tightened up?
If deployments at your company are stressful instead of routine, I can help you build a pipeline that makes them boring — in the good way.
Let's talk →