The software delivery lifecycle
The path every change takes from an idea to running in production — and back again as feedback.
Why it matters
Most problems in real projects happen between the steps: code that works locally but not on the server, a fix nobody reviewed, an outage nobody noticed. Knowing the whole path tells you which skill is missing when something goes wrong.
Where it fits
What you will learn
- Name the stages a change passes through before users see it.
- Explain what each stage protects against.
- Recognise the capabilities that apply to every stage: security, configuration, observability and documentation.
Before you start
Nothing — this is a good place to start.
One change, many steps
A change starts as a goal ("users can reset their password"), becomes code, is recorded in version control, is checked automatically, is built into something deployable, is released to a server and is then watched in production. What you learn there feeds the next plan.
- Plan & Design
- Develop
- Version control
- Verify
- Build & Package
- CI/CD
- Deploy
- Operate
What each stage protects against
- Plan & Design — building the wrong thing, or a design that cannot grow.
- Develop — code that is hard to read, change or run.
- Version control — lost work and changes nobody can explain later.
- Verify — bugs and known vulnerabilities reaching users.
- Build & Package — "works on my machine": the same artifact must run everywhere.
- CI/CD — skipped checks and manual, error-prone releases.
- Deploy — downtime and broken releases that cannot be rolled back.
- Operate — problems users notice before you do, and data you cannot recover.
Capabilities that cut across
Some skills are not a step but a habit at every step. Security starts with the first commit (no secrets in Git) and ends with patched servers. Configuration keeps environment-specific settings out of the code. Observability makes the running system explain itself. Documentation lets the next person run and change the project.
Tip: You do not need every skill at once. Use the map to find the stage where your project hurts most and start there.
- I can describe how a change in my project reaches production.
- I know which checks run before a change is merged.
- I know where to look when production misbehaves.
Official documentation and references
Guides
- Pro Git — Getting Started ↗ Official · Git project — The official Git book; the first chapter explains why version control sits at the centre of the path.
Reference
- Monitoring Distributed Systems (Site Reliability Engineering) ↗ Google SRE book — How operating a system feeds back into what you build next.
Learn next
- Git basics ›✓ Learned
Related topics
- Architecture decisions and diagrams✓ Learned
- Project documentation✓ Learned
- Git basics✓ Learned
- CI/CD pipelines✓ Learned
Done with this topic?
Reviewed 2026-10-23. Links go to the official documentation unless marked otherwise.