Zurich followed DevOps and Agile industry trends as they organized their ITSM development efforts. However, over time cloning began taking more and more hours, requiring clones to be executed over weekends. Cloning on weekends meant that admins had to work weekends to import pre-clone development work into the cloned sub-prod instances – an effort that also took many person-hours to complete. Additionally, the number of developers writing ServiceNow code produced a volume of work that made comparing changes across instances in preparation for code pushes too laborious and time-consuming. In short, a significant percentage of developer and admin time was spent reviewing and preparing for deployments rather than writing code.
Reduce Development Lead Time
Developers can’t code updates during cloning blackout dates. This fact didn’t use to represent a challenge as cloning was done during non-productive hours such as weekends or evenings. However, with cloning taking 20+ (and growing) hours to complete, there has been pressure to reduce the lead time required to have newly minted clones ready for developers.
Reduce Deployment Lead Time
Preparing for production deployments is time-consuming. Zurich spent days cross-checking spreadsheets and manually inspecting update sets in multiple browser tabs across their sub-prod instances. Even with this attention to detail, it was still difficult to precisely determine the number and ordering of update sets, scripts, etc. in their pre-prod instance that were ready for prod.
Improve Change Failure Rate
Zurich wanted to reduce the number of post-deployment conflicts resulting from siloed instances being out of sync.
Reduce Privileged Access
With so many developers coding updates in parallel elevated privileges were granted to developers so they could promote their update sets to pre-prod instances. Though this is a common practice in the industry and the risk is understood, this still creates privilege sprawl which is not the ideal of any access management best practice.