Before this:What is deployment?
The deployment lifecycle
Key takeaways Shipping software is a repeating loop, not a one-off event. A change moves through build (source to artifact), test (prove it works), release (package and version), deploy (put it where it runs), and operate (keep it healthy) — then what you learn operating feeds the next build. Every lesson in this module lives at one of these stages.
What is deployment? framed the problem: getting code from your machine to a running service other people use. This lesson gives you the map — the five stages a change repeats forever — so the rest of the module has a place to hang.
Why think in a lifecycle at all?
A single deploy feels like a straight line: write code, ship it, done. But real software is never done. You fix a bug, add a feature, patch a security hole — and each change retraces the same path. Naming that path as a cycle does two things: it makes every step deliberate instead of ad-hoc, and it makes the operate stage feed back into the next build so you actually learn from production.
What happens at each stage?
Each stage has a clear job and a matching lesson later in this module:
| Stage | The job | Where this module covers it |
|---|---|---|
| Build | Turn source into a single, reproducible artifact | Build artifacts & versioning, Writing a Dockerfile |
| Test | Prove the artifact works before anyone relies on it | CI/CD pipelines |
| Release | Version, package, and publish it so it can be pulled | Images & registries, Release strategies |
| Deploy | Put it where it runs and start it | Cloud & VPS, Zero-downtime deploys |
| Operate | Keep it healthy, watch it, fix it, feed back | Observability, Incident response |
Where does automation fit?
The first three stages — build, test, release — are exactly what a CI/CD pipeline automates. A push or a version tag triggers a fresh machine to build the artifact, run the tests, and publish the result, identically every time. GopherTrunk does this with GitHub Actions: every pull request is built and tested, and a version tag builds and publishes the downloadable release binaries. Automating the left of the loop is what makes going around it fast and boring — which is what you want.
Why does operate loop back to build?
The last stage is the one beginners skip. Once a version is live you have to operate it: read its logs, watch its metrics, respond when it breaks. Everything you learn there — a slow endpoint, a crash under load, a confusing config — becomes a bug report or a feature request that starts the loop again with a new build. A deployment you can’t observe is a loop with the feedback wire cut; you’ll keep shipping the same problems.
Quick check: what makes the deployment lifecycle a loop rather than a line?
Recap
- Deployment is a repeating loop: build, test, release, deploy, operate.
- Build makes an artifact, test proves it, release versions it, deploy runs it, operate keeps it healthy.
- CI/CD automates the build-test-release stages so going around the loop is fast.
- Operate feeds what you learn back into the next build — that feedback is the point of the loop.
Next up: the environments a build runs in, and keeping config out of code.
Frequently asked questions
What are the stages of the deployment lifecycle?
A common way to name them is build, test, release, deploy, and operate. Build turns source into an artifact, test proves it works, release packages and versions it, deploy puts it where it runs, and operate keeps it healthy and feeds problems back into the next build. It’s a loop, not a line — every change goes around it again.
Is the deployment lifecycle the same as CI/CD?
CI/CD is the automation that runs the build, test, and release stages for you on every change. The lifecycle is the bigger picture — it also includes deploying to a server and operating it in production. CI/CD automates the left-hand stages; you still design the deploy and operate ones.