Cloud Integrations
MOD_06 / SECTION_02 // DEVOPS · DEPLOY
MODULE READY

Automate and enable low-risk releases

Even with great tests, most teams deploy infrequently because deploys are manual, slow, painful, and involve a Dev/Ops handoff. Fix: make the deploy automated, repeatable, predictable, and self-service. Facebook normalized the practice; Etsy and CSG show the pattern in regular companies.

Facebook made code deployment part of every engineer's daily work by making it low-risk and automated. That requires deploys to be automated, repeatable, and predictable — and the same process across all environments. The handoff between Dev and Ops disappears.

// requirements for a deploy pipeline that you trust
req 01
Same deploy to every env

Dev, test, prod — same mechanism. Prod deploy has already been rehearsed dozens of times earlier in the pipeline.

req 02
Smoke-test the deploy

After deploy, verify connection to DBs, message buses, external services. Run a real transaction. On failure, fail the deploy.

req 03
Environments stay in sync

Single-step env builds (Module 04). Re-validate sync continuously, not at release time.

// self-service deploys · the build / test / deploy contract

Either Dev or Ops can promote code, ideally without any manual steps or handoffs. Three capabilities make this possible:

build

Pipeline creates a packaged artifact from version control. Same artifact deployable to any environment.

test

Anyone can run any or all of the automated test suites — locally or against test infrastructure.

deploy

Anyone with access can deploy by running scripts checked into version control. Even prod, where authorized.

Containers and modern orchestrators mean the most complex deploys can complete in seconds to minutes. The "deploy code" button is real — once you build the substrate behind it.

// case studies
// csg international (2013)

Telecom billing platform → daily deploys to production. Demonstrated that even a regulated, legacy-heavy enterprise can ship daily once the pipeline + env discipline is in place. Stopped treating release day as an event.

download Case study · PDF ~560 KB
// etsy self-service (2014)

Every Etsy engineer could deploy to production on their first day. The first commit most new hires made was a one-line web change they then deployed themselves — immediate ownership, immediate confidence in the safety net.

download Case study · PDF ~480 KB
// dora · what elite + high performers look like

Forsgren et al's State of DevOps research (2019): elite performers deploy on-demand, multiple times a day, with lead time for changes under an hour, change-failure rates in single digits, and MTTR also under an hour. Low performers are 1000x+ slower on every dimension. The gap is not talent; it is the practices in Modules 04–06.

help Knowledge Check
Question 1/2

A team deploys nightly via a 90-step runbook executed by 2 ops engineers. Most failures happen at step 47 — a misconfigured connection string. What's the most leveraged fix?

// pick one to verify

help Knowledge Check
Question 2/2

An engineer says: "We can't let devs self-deploy — they'll break production." Is this argument correct?

// pick one to verify