Deployment request states
Summarize
Summary of Deployment request states
Deployment requests in ServiceNow's release process transition through several distinct states that manage and track the progression of update sets from development to deployment. Understanding these states helps ensure the deployment request is properly assessed, reconciled, and executed within a release cycle.
Show less
Deployment Request States and Their Purpose
- Draft: Initial state where the deployment request is not yet linked to a release. Developers add update sets only in this state and keep the request here until the work is complete and ready for assessment.
- Ready for Assessment: Indicates the deployment request is functionally complete and ready to trigger the assessment playbook. This initiates automated tests and instance scans as part of the release pipeline.
- Assessing: Automated Test Framework (ATF) tests, instance scans, and playbook processes run to validate the deployment request. The update sets move from development to testing. The assessment either confirms readiness or generates deployment tasks for issues found.
- Reconciling: Focuses on resolving open deployment tasks generated during assessment (such as test failures or conflicts). These tasks require outcomes like code fixes, test suite updates, or approvals. Once resolved, the request is reassessed.
- Ready for Deployment: All assessments and reconciliations are complete, and the request is locked from further changes. On-demand deployments proceed immediately; scheduled deployments wait for the release time.
- Deploying: The deployment request is actively deploying its update sets as part of the release.
- Complete: The deployment request has been successfully deployed within the release.
- Failed: Deployment encountered issues requiring manual intervention before resubmission.
- Cancelled: The deployment request was manually canceled and will not proceed.
Why This Matters
By following these defined states, ServiceNow customers can systematically validate and manage deployment requests, ensuring quality and readiness before deployment. This structured process minimizes deployment risks, tracks remediation tasks, and supports automated testing and approval workflows integral to a successful release.
What to Expect
Customers can expect that deployment requests will move through automated assessments and possible reconciliation loops until all issues are resolved. Once ready, requests are locked for deployment and executed either on-demand or as scheduled. If problems arise, customers receive actionable tasks or status updates requiring manual resolution to maintain release quality and integrity.
A deployment request might be in one of several different states during the release process.
| State | Description |
|---|---|
| Draft |
The deployment request hasn’t yet been associated with a release. Draft is the only state in which an update set can be added to a deployment request. A developer keeps their deployment request in Draft state until they believe the work associated with it is complete. It shouldn’t be moved into the Ready for Assessment state until the developer is comfortable with it being deployed as-is. |
| Ready for Assessment |
The developer creating the deployment request has determined that it’s a functional and complete unit and is ready to be deployed. This state is the triggering condition for the assessment playbook. Immediately after the developer selects Ready to Assess, assessment will begin, running the processes, tests, and checks defined in the release pipeline. |
| Assessing |
Automated Test Framework (ATF) tests are running, instance scans are running, and any Playbooks (PAD) process that will determine the suitability of this deployment request to be deployed is executed. Update sets contained within the deployment request are being moved from the development instance to the test instance. The Assessment phase results in one of two conclusions:
|
| Reconciling |
Open deployment tasks have been generated for action. These tasks must have an outcome for the assessment to be completed and the deployment request to move into the next stage. The sample pipelines included in ReleaseOps will create deployment tasks for preview conflicts and ATF test failures. Some outcomes might involve code changes or additions, updates to test suites or configuration, or approvals or sign-offs. After all open deployment tasks have an outcome, the request is reassessed. |
| Ready for Deployment |
All assessments have been performed, and all reconciliations are complete. No new update sets can be added in this state, and the deployment request is effectively locked. If changes must be made at this point, the deployment request must be canceled. At this point, if the deployment request is an on-demand deployment, it will continue immediately into deployment. Otherwise, it waits for the scheduled time of the release before continuing. |
| Deploying |
A release is in the process of deploying the update sets associated with this deployment request. |
| Complete |
The deployment request was successfully deployed as part of a release. |
| Failed |
The deployment request had a problem that requires manual intervention or resolution to be resubmitted for a release. |
| Cancelled |
The deployment request was manually canceled. |