Overview
Build a release and deployment management process that satisfies ISO/IEC 20000-1:2011 Clause 9.3. This skill guides you through defining a release policy with typed releases, documenting the full release lifecycle with entry and exit criteria, establishing acceptance criteria, defining deployment methods and communication, and creating rollback procedures for when things go wrong.
Releases are the mechanism through which changes reach the live environment. A poorly managed release can undo months of stable service. Auditors expect to see that releases are planned, built, tested in a controlled environment, formally accepted before deployment, and reviewed after go-live. This skill ensures your release process is systematic and auditable, from a routine patch to a major platform upgrade.
For a step-by-step walkthrough, see the ISO 20000 SMS workspace tutorial .
What It Covers
- Release policy – major, minor, patch, and emergency types with frequency and scope
- Release lifecycle – plan, build, test, accept, deploy, review with entry/exit criteria
- Acceptance criteria – functional tests, performance tests, security checks, operational readiness
- Deployment procedures – methods (blue-green, rolling, big-bang), communication, verification
- Rollback procedures – trigger criteria, step-by-step instructions, stakeholder communication
- Process integrations – every release requires an approved change, CMDB updated after deployment
Example Conversation
You: We need to set up release and deployment management for ISO 20000. We deploy software for our managed service clients and we need a formal process. Currently deployments are ad-hoc and sometimes things break in production.
Agent: A formal release process will address that. Let me help you build one for Clause 9.3. First, let’s define your release types. I’d recommend:
Type Scope Typical Frequency Major Significant new functionality or architecture changes Quarterly Minor Enhancements and non-critical fixes Monthly or sprint-based Patch Bug fixes and security updates As needed Emergency Critical fixes for active incidents Immediate Does this classification work for your environment?
You: Yes. Major releases happen roughly quarterly, minor releases every two weeks aligned with our sprint cadence, patches as needed, and emergency releases for P1 incidents.
Agent: Now let’s define acceptance criteria. Before any release goes to production, what must pass?
You: Functional testing in staging, performance tests for major releases, security scan, updated documentation, and sign-off from the client’s technical lead.
Agent: Here are the proposed acceptance criteria:
- All functional tests passed in staging environment
- Performance tests passed (major and minor releases)
- Security vulnerability scan completed with no critical findings
- Release notes and updated documentation reviewed
- Client technical lead sign-off obtained
- Operational readiness confirmed (monitoring, alerts, runbooks)
Now let’s discuss deployment methods. What approach do you use?
You: Blue-green deployment for our cloud-hosted services. For on-premise client environments, we do scheduled maintenance window deployments.
Agent: Good. Let me define the rollback procedure. Rollback is critical – what criteria should trigger it?
You: If we see a critical defect within 2 hours of deployment, or if service availability drops below 99% during the deployment window.
Agent: Here’s the rollback procedure:
- Trigger: Critical defect detected or availability below 99% within 2 hours
- Decision: Release manager authorizes rollback (or incident manager for emergency)
- Execute: Switch traffic back to previous version (blue-green) or restore from backup (on-premise)
- Verify: Confirm service restoration and run smoke tests
- Communicate: Notify service desk, affected clients, and CAB within 30 minutes
- Post-rollback: Root cause analysis and updated release plan
You: That’s exactly what we need.
Agent: I’ll run the
release_process_validatornow…Result: All checks passed. 4 release types defined (major, minor, patch, emergency). 6 lifecycle stages documented. 6 acceptance criteria established. Rollback procedure with trigger criteria, steps, and communication plan. Integration with change management and configuration management documented.
Sample Output Excerpt
The skill produces a structured JSON process file and a markdown process document. Here is a representative excerpt from the JSON.
{
"release_types": [
{ "type": "major", "description": "Significant new functionality or architecture changes", "frequency": "quarterly", "approval": "CAB + service owner" },
{ "type": "minor", "description": "Enhancements and non-critical fixes", "frequency": "bi-weekly (sprint)", "approval": "CAB" },
{ "type": "patch", "description": "Bug fixes and security updates", "frequency": "as_needed", "approval": "Change manager" },
{ "type": "emergency", "description": "Critical fixes for active incidents", "frequency": "immediate", "approval": "Emergency CAB" }
],
"lifecycle_stages": ["plan", "build", "test", "accept", "deploy", "review"],
"acceptance_criteria": [
"Functional tests passed in staging",
"Performance tests passed (major/minor)",
"Security scan completed — no critical findings",
"Release notes and documentation reviewed",
"Client technical lead sign-off",
"Operational readiness confirmed"
],
"deployment_methods": {
"cloud": "Blue-green deployment with traffic switch",
"on_premise": "Scheduled maintenance window with backup"
},
"rollback_procedure": {
"trigger_criteria": "Critical defect or availability below 99% within 2 hours of deployment",
"steps": [
"Release manager authorizes rollback",
"Switch to previous version (blue-green) or restore from backup",
"Verify service restoration and run smoke tests",
"Notify service desk, clients, and CAB within 30 minutes",
"Conduct root cause analysis"
],
"communication": "Service desk, affected clients, and CAB notified within 30 minutes"
},
"integrations": {
"change_management": "Every release requires an approved change request",
"configuration_management": "CMDB updated after every deployment"
}
}
Extension Tools
release_process_validator
Validates release-process.json for ISO 20000-1 Clause 9.3 completeness. Run after generating the release process.
| Check | What It Does |
|---|---|
| Release types | Confirms major, minor, patch, and emergency types are defined |
| Lifecycle stages | Verifies all required stages are present (plan through review) |
| Acceptance criteria | Checks that release acceptance criteria are documented |
| Rollback procedure | Validates trigger criteria, rollback steps, and communication plan |
| Process integrations | Confirms integration with change management and configuration management |
Getting Started
Activate the ISO 20000-1 Release and Deployment Management skill after you have the change management process in place – every release requires an approved change request. Have your deployment methods, testing environments, and client sign-off requirements ready.
The completed release process is the final step in the control chain: changes are approved through change management, releases are planned and deployed through this process, and the CMDB is updated to reflect the new state of the environment.