Principle 5 - On-Demand Deployments
On demand deployment builds upon the automation recommended in principle of Speed. There are two phases (1) Continuous Delivery and (2) Continuous Deployment.
Continuous Delivery
Continuous Delivery (CD) is a practice that is applicable to ServiceNow production releases. The goal is to make release payloads available for deployment to your production instance(s). CD accomplishes this goal by implementing the pervasive automation described in principle 2, Visibility.
Continuous Deployment
Continuous Deployment (never abbreviated) is a practice that builds upon CD. CD makes release payloads available for production. Continuous Deployment goes one step further and automatically deploys into production. This isn’t as risky or scary as it seems. Consider that the same automation mechanics that will be used for production deployment will have been tested and vetted across all your sub-prod instances. Automated production deployments are built on previous successes in sub-prod instances.
Remediation Propagation
Despite everything covered so far, conflicts will arise and they need to be addressed. On demand deployments stipulate that these remediation steps be recorded and played back as part of your deployment automation and continuous syncing. In other words, the remediation steps associated with a specific update set conflict need to be propagated throughout your ServiceNow ecosystem. Continually remediating the same error is a form of manual task that must be automated. This keeps your ecosystem as production-like as possible and ensures you can practice phase two, Continuous Deployment.
Change Requests
On-demand deployments not only use automation native to ServiceNow but also integrate that automation into ServiceNow Change Requests. On-demand deployments emphasize speed and agility with traceability. ServiceNow was built to be a system of record for change (among other datasets), and customizations, features, and apps to ServiceNow should be included in that record.
Anytime, Anywhere
On-demand deployments should be able to happen by click, schedule, or triggerable action (e.g., a change request update, successful test completion, or a specific time has come). Your scheduling system should also include blackout dates to help safeguard you from making deployments during unsafe windows. This safeguard implies that triggered, automated, and click deployment are tied to your blackout calendar.
Can you override blackout windows? Absolutely, but remember all deployment actions, whether manual or automatic, create forensic records. On-demand deployments mean you always have complete visibility before and after deployments. Remember, On-demand deployments mean you have speed and agility with safety.