Deployment principles are the rules that keep a release boring. Tools change; these do not: same artifact, small steps, observable, reversible, owned by the team that writes the code.
The short list
- Reproducible: SHA in, artifact out. Pin toolchains.
- Automated: a human should not be the only person who knows the click path. Humans still approve when the risk is high.
- Incremental: a change you can undo this afternoon. Feature flags for behavior; expand/contract for schema.
- Observable: after deploy, latency, errors, and a smoke check — not “the pipeline was green.”
- Reversible: previous artifact still exists; DB migrations have a documented forward-fix if they cannot roll back.
- Least privilege: the deploy identity can ship this app, not the whole subscription.
You build it, you run it
The team that merges is on the hook for the pager. A separate “release engineering” queue that does not understand the app will ship the wrong config at 2 a.m.
Example
Staging and production run the artifact the test job already produced, for the same git SHA.
What breaks it
Production pulls the branch and compiles on the server. That binary is not the one CI tested.
git pull
dotnet build -c ReleasePitfalls
- Friday deploys with no owner on the weekend (policy, not superstition — coverage).
- Snowflake prod that drifted from IaC.
- One pipeline for twelve unrelated apps that cannot deploy independently.
See Software Deployment and infrastructure.