Part 1: Software Delivery Mental Models & the SDLC

Why Mental Models First

Most engineers learn software delivery backwards. They start with a tool — Jenkins, GitHub Actions, Docker — and try to figure out where it fits. This is like learning to drive by memorising the dashboard before understanding what a car does or where roads go.

Mental models are the maps you carry in your head. They let you evaluate any tool, any workflow, and any process by asking: Where does this fit in the system? What problem does it solve? What tradeoff does it introduce?

The Factory Analogy

Think of software delivery as a factory assembly line. Raw materials (source code) enter one end. A finished, tested, packaged product (a deployed application) exits the other. Between those two points, a series of stations transform the code:

• Quality inspection (automated tests)
• Assembly (compilation and bundling)
• Packaging (Docker images, JAR files, binaries)
• Shipping (deployment to servers)
• Monitoring (observability in production)

Just as a manufacturing plant optimises for throughput, quality, and safety, a software delivery system optimises for deployment frequency, change failure rate, and recovery time.

The Software Delivery Lifecycle (SDLC)

The SDLC is the backbone mental model. Every software change — from a one-line bug fix to a complete platform migration — flows through these stages. The stages are universal; only the speed and automation level vary between organisations.

flowchart TD
    A[Plan] --> B[Code]
    B --> C[Build]
    C --> D[Test]
    D --> E[Package]
    E --> F[Release]
    F --> G[Deploy]
    G --> H[Operate]
    H --> I[Observe]
    I --> J[Improve]
    J --> A
                            

The Ten Stages Explained

Linear vs Cyclic Thinking

The diagram above is drawn as a cycle intentionally. Early software development treated these stages as a linear waterfall — you completed Plan, then moved to Code, and never went back. Modern teams understand that:

• The cycle runs continuously — there is no "done" state
• The cycle runs at different speeds — some teams complete it in minutes (deploying dozens of times per day), others take months
• Multiple cycles run in parallel — different features are at different stages simultaneously
• Feedback from later stages modifies earlier ones — observability data changes planning priorities

A Real-World SDLC Walk-Through

Let us trace a single bug fix through the entire lifecycle at a mid-sized SaaS company:

1. Plan: Customer reports a login failure. Support creates a Jira ticket. The team prioritises it for the current sprint.
2. Code: A developer creates a feature branch, fixes the authentication logic, and opens a pull request. A colleague reviews the code.
3. Build: The CI server detects the PR, checks out the code, and runs npm install && npm run build. The build succeeds.
4. Test: The pipeline executes 2,400 unit tests, 180 integration tests, and 12 end-to-end tests. All pass.
5. Package: A Docker image is built with the fix, tagged v2.14.1, and pushed to the container registry.
6. Release: The PR is merged to main. A GitHub Release is created with changelog notes.
7. Deploy: Argo CD detects the new image tag in the GitOps repository and rolls out the update to the staging cluster, then to production using a canary strategy.
8. Operate: Kubernetes health checks confirm the new pods are serving traffic. The old pods are terminated.
9. Observe: Grafana dashboards show the login error rate dropping from 2.3% to 0.01%. Datadog confirms latency is unchanged.
10. Improve: The team discusses why the bug was not caught earlier. They add a new integration test to prevent regression.

Total elapsed time: 47 minutes from commit to production. This is the power of a well-automated delivery pipeline.

Continuous Integration & Continuous Delivery

CI and CD are the two most important concepts in modern software delivery. They are often mentioned together as "CI/CD" but represent distinct practices with different goals.

Continuous Integration (CI)

CI is the practice of merging developer code changes into a shared branch frequently — at least once per day — and automatically verifying each merge with builds and tests.

flowchart LR
    A[Developer pushes code] --> B[CI Server triggered]
    B --> C[Checkout & Build]
    C --> D{Tests Pass?}
    D -->|Yes| E[Merge to main]
    D -->|No| F[Notify developer]
    F --> A
                            

The key goals of CI are:

• Fast feedback — know within minutes whether a change breaks something
• Integration confidence — prove that changes from different developers work together
• Regression prevention — catch bugs introduced by new code before they reach users

Continuous Delivery vs Continuous Deployment

These two terms sound similar but have a critical difference:

Most organisations practice Continuous Delivery. Continuous Deployment requires extremely high test confidence and sophisticated rollback mechanisms.

Deployment vs Release

This distinction is subtle but important:

• Deployment = placing new code on production servers. The code is running but not necessarily visible to users.
• Release = making a deployed feature available to users. This can happen instantly or gradually via feature flags.

By separating deployment from release, teams can deploy code safely (it is live but hidden behind a flag) and then release it to 1% of users, then 10%, then 100%. If something goes wrong at 1%, you flip the flag — no rollback needed.

Five Core Delivery Principles

Every decision in software delivery — from choosing a branching strategy to designing a deployment pipeline — should be evaluated against these five principles.

1. Automation

If a human has to do it more than twice, automate it. Manual steps are slow, error-prone, and do not scale. Automation is not just "writing scripts" — it is designing systems where the default path requires zero human intervention.

# Bad: Manual deployment
ssh production-server
cd /app
git pull origin main
npm install
npm run build
pm2 restart app

# Good: Automated deployment triggered by merge to main
# (This happens automatically in CI/CD — no human SSH required)

2. Reproducibility

Any build, test, or deployment should produce the same result regardless of when or where it runs. If a build works on your machine but fails in CI, your build is not reproducible.

Reproducibility requires:

• Pinned dependencies — lock files (package-lock.json, poetry.lock) ensure identical versions
• Containerised environments — Docker ensures identical OS, libraries, and runtimes
• Hermetic builds — the build does not depend on anything outside the repository

3. Idempotency

Running the same operation twice should produce the same result as running it once. This is critical for deployments — if a deployment script runs twice (due to a retry or network glitch), it should not create duplicate resources or corrupt state.

# Non-idempotent (dangerous): creates a new user every time
curl -X POST https://api.example.com/users -d '{"name": "admin"}'

# Idempotent (safe): creates or updates — same result either way
curl -X PUT https://api.example.com/users/admin -d '{"name": "admin"}'

4. Fast Feedback

The faster a developer learns that something is broken, the cheaper it is to fix. A bug caught in 2 minutes (by a local unit test) costs seconds to fix. The same bug caught in 2 weeks (by a customer in production) costs hours of debugging, a hotfix deployment, and reputational damage.

flowchart LR
    A["Local test\n~$1"] --> B["CI pipeline\n~$10"]
    B --> C["Staging\n~$100"]
    C --> D["Production\n~$1,000"]
    D --> E["Customer report\n~$10,000"]
                            

5. Safe Deployments

Every deployment should be reversible. If something goes wrong, you need a way to return to the previous known-good state within minutes, not hours. Safe deployment techniques include:

• Blue-green deployments — two identical environments; switch traffic between them
• Canary releases — route a small percentage of traffic to the new version first
• Feature flags — toggle features without deploying new code
• Immutable artifacts — never modify a deployed artifact; always deploy a new one

Feedback Loops

Feedback loops are the nervous system of software delivery. They tell you whether your changes are safe, your system is healthy, and your users are happy. The faster and tighter these loops, the better your delivery system.

Inner Loop vs Outer Loop

Loop Speed Matters

Research from the DORA (DevOps Research and Assessment) team shows that elite performers have feedback loops that are orders of magnitude faster than low performers:

These are known as the DORA Four Key Metrics, and we will explore them in depth in Part 25.

Why Learn Software Engineering?

Whether you are a developer, QA engineer, DevOps specialist, platform engineer, or engineering manager, understanding the full delivery lifecycle gives you superpowers:

• For developers: You stop writing code in a vacuum. You understand why builds break, why tests matter, and how your code reaches users.
• For QA engineers: You shift from gatekeeper to enabler. You design tests that integrate into the pipeline, not after it.
• For DevOps/Platform engineers: You design systems that serve developers, not frustrate them. You optimise the right bottlenecks.
• For managers: You make informed decisions about tooling, process, and team structure based on delivery principles, not vendor pitches.

Exercises

Test your understanding of the mental models covered in this article.

Conclusion & Next Steps

You now have the foundational mental models of software delivery — the SDLC cycle, CI/CD principles, the deployment-vs-release distinction, five core principles, and the feedback loop framework. Every topic in this series builds on these concepts.

The critical takeaway is this: software delivery is really automation + reliability + controlled change management. Tools change. Platforms change. These principles do not.