CI/CD & Deployment
Pipeline infrastructure and its identity, building an artifact once and promoting it unchanged, the four rollout strategies and what each buys, version compatibility during a rolling deploy, and shutting down without dropping in-flight work.
Git push → CI → test → build → artifact → deploy → production. The part people skip: the pipeline holds production credentials, so it is a production system with a production identity, and it is the most attractive target in the estate.
Q · What actually happens between a commit and running code, and what does the machinery in the middle have permission to do?
The artifact that passed staging must be the artifact that reaches production — the same image digest, not a rebuild from the same tag. Rebuilding per environment means staging tested something that no longer exists.
Q · If staging passed, what exactly did it prove — and is that thing the same thing that reaches production?
Recreate, rolling, blue/green and canary. They differ on rollout speed, rollback speed, capacity cost, risk exposure and what compatibility they demand of your code and schema — and the compatibility column is the one that decides most real arguments.
Q · Which rollout strategy fits this workload, and what does each one demand from the code and the database in return?
V1 V1 V1 V1 → V2 V1 V1 V1 → V2 V2 V1 V1 → V2 V2 V2 V2. Capacity stays flat and there is no window — in exchange, both versions serve traffic against one database, so every change must be backward compatible for at least one release.
Q · What must be true about my code and my schema before replacing instances a batch at a time is actually safe?
Blue is what is serving. Green is the new version, fully built and verified while nobody is looking. The switch is a load balancer change and rollback is the same change in reverse — which is why it is the fastest rollback there is, and why the database, which does not switch, is the part that ruins it.
Q · How do I get a rollback measured in seconds, and what does the database do while the application environment is being swapped underneath it?
95% to the current version, 5% to the new one, then increase — but only if the metrics say so. The strategy has the smallest blast radius of the four and one hard prerequisite: without per-version metrics you can decide on, a canary is just a slow rolling deploy that cost you a routing layer.
Q · How do I expose a new version to real production traffic while limiting the damage a bad one can do — and what has to exist before that is more than theatre?
Shipping the code and turning the behaviour on can be two separate operations, minutes or months apart. That decoupling is the most powerful risk-management tool in delivery — and it buys itself with flag debt, a combinatorial test surface, and a second control plane nobody treats as production.
Q · What changes when the decision to run new code and the decision to expose new behaviour stop being the same event?
Deployment starts → stop accepting new traffic → finish in-flight work → close resources → terminate. Skip the middle and every deploy drops the requests that were in progress, producing a small, regular spike of 502s that gets explained away as "just the deploy".
Q · What must a process do between being told to stop and actually stopping, so that no request in progress is lost?