Agile Service Transition and Deployment Practices
Agile Service Transition and Deployment Practices
This domain tests how changes reach production safely and repeatedly, and whether you understand that deployment and release are separate decisions.
Decoupling deployment from release
Deployment is putting an artifact into an environment; release is making functionality available to users. Feature toggles, dark launches and canary exposure let a team deploy many times a day while releasing rarely and reversibly. This decoupling is what makes small batches compatible with control.
Pipeline practice
- Build once, promote the same artifact through environments; never rebuild per stage.
- Test automation follows the pyramid: many fast unit tests, fewer service tests, very few end-to-end UI tests.
- Deployment patterns: blue-green for instant rollback, canary for progressive exposure, rolling for capacity efficiency.
- Every deployment has explicit success criteria and a rollback trigger agreed before it starts.
Transition is part of the value stream
Support readiness is a delivery item, not an afterthought: runbooks, monitoring and alert thresholds, knowledge articles, service desk briefing, known-error entries, licence and capacity checks. Shift-left means testing operability and security during development rather than discovering them at cutover. Retrospectives after significant transitions feed actions back into the backlog with owners.
Change records without a parallel process
Record the change once, attached to the backlog item, and let the pipeline capture approval, test evidence, artifact hash and deployer identity. High-risk exposure - enabling a toggle for all users - carries its own assessment, which may differ from the risk of the deployment itself.
Worked example
A team deploys daily but releases weekly behind a toggle. An auditor asks when the financial-reporting change was authorised. Reasoning: the deployment is low risk because the toggle is off; the authorising event is the toggle enablement, which is itself a change with a risk assessment, approval and rollback plan. The change record must therefore reference the enablement, not only the deployment, or the audit trail answers the wrong question.
Traps
Assuming CI/CD removes the need for change control; treating testing as a phase after build; big-bang cutover with no rollback criterion; recording changes only at deployment when the risk sits at release; leaving support teams to discover the change after go-live.