Curated from three recovered SDLC policy documents.
A delivery lifecycle is useful when it makes responsibility and evidence clearer. It is less useful as a ceremonial document that declares every team responsible for everything.
The essential chain is simple: understand the need, design the boundary, build the smallest coherent change, test it, release it deliberately, and continue observing it after release.
1. Define the need
Capture the user outcome, functional and non-functional requirements, data involved, constraints, acceptance criteria, and explicit exclusions. Security begins here because this is where the system first decides what it will trust.
Evidence: decision record, acceptance criteria, data classification, threat assumptions, and an owner.
2. Design the boundary
Describe the architecture, data flows, authentication and authorisation decisions, external dependencies, failure modes, and recovery path. Review dangerous operations while they are still diagrams.
Evidence: architecture note, interface contract, abuse cases, rollback plan, and observability plan.
3. Build inspectably
Use version control, focused reviews, managed dependencies, automated checks, and documentation near the code that enforces the behaviour. Security and operations should be collaborators in the design, not late-stage gates.
Evidence: review history, automated test results, dependency provenance, and reproducible build instructions.
4. Test the real path
Unit and integration checks matter, but they do not prove the deployed journey. Exercise permissions, migrations, failure recovery, performance, and the user-visible path in an environment that represents reality.
Evidence: test records, defect decisions, security results, and a release-specific verification checklist.
5. Release deliberately
A build existing is not the same as a product being available. Name the gates: built, signed, deployed, submitted, reviewed, released, and observable. Know which steps are reversible and which need explicit confirmation.
Evidence: immutable artefact, release notes, migration and rollback procedures, approval record, and health checks.
6. Maintain the system
Production creates new information. Monitor availability and security signals, test backups through restoration, patch dependencies, handle incidents, and feed user evidence back into requirements.
Evidence: alerts with owners, restore tests, incident records, change history, and verified remediation.
The hand-off rule
Every stage should leave the next person three things: the current truth, the evidence behind it, and a safe way back. If any one is missing, the lifecycle has a blind spot.