Disclaimer
This workflow hasn't been tested and I'm using this more to jot down my and my teams discoveries with setting up a SDLC using CI/CD, Azure DevOps and ServiceNow. This is a draft document and may change overtime. Even though it's not fully vetted or in production use, I think this will provide some value to the NOW Developer Community for any other teams attempting to do something similar.
The information in this paper came from the contributions and shared experience of pervious and current developers on the UCF IT Data Systems and Digital Transformation Team.
Introduction
Coming from a Full Stack Development background, my team and I have been trying to bring our existing Software Development Release Life Cycle to ServiceNow. Typically our developers work independently on backlog items on their local machines and then commit their changes to Azure DevOps (ADO) so that a Pull Request (PR) may be approved before their changes are merged into a development branch. From there we use Azure Pipelines to automatically deploy changes from our development branch to a development server for testing. Once we're ready to release to production a merge from development to our main branch is created and a Azure Releases are created to deploy to our QA and Production environments based on a manual approval.
Setting up an Environment
In this draft design, we'll need the following branches to commit our changes to as well as the following ServiceNow instances to deploy to:
Branches
- PR - All developers will sync their changes here using stashing
- Dev - This branch is where approved PR changes are deployed to and triggers releases to the ServiceNow dev instance.
- Main - This is the branch that final changes are committed to and deploys the release process to QA an Production ServiceNow instances.
ServiceNow Instances
- Personal Developer Instance (PDI)
- ServiceNow Dev Instance
- ServiceNow QA Instance
- ServiceNow Prod Instance
Once you have all of this setup , we'll want to add a credential for our Azure DevOps Git repository and connect that to our project in Studio.
Branching, Merging and Conflict with ServiceNow
The first issue to overcome when trying to develop on a local environment with ServiceNow, is getting an isolated development environment. Luckily, ServiceNow provides free Personal Developer Instances (PDI) for you to use. These do work, but they do have the drawback of not being integrated with your companies environment (i.e. Active Directory access). You could purchases instances in your company environment, but I've heard that this is quite pricey... so a PDI it is.
With a PDI, you can then begin work by creating a working branch off of the "PR" branch so that you can make changes and then commit them. However, we're not going to directly commit to our ADO repo, we're first going to make a stash within Studio instead. The reason we do this is because if you have multiple developers working on some changes and then have them commit directly tot he repository, you will run into conflicts when you attempt to merge the changes from Azure DevOps (this would also be true in any other environment.), especially from the checksum.txt file. Let me provide and example:
- Developer A creates a branch off of PR
- Developer B creates a branch off of PR
- Developer B makes a change, commits their branch to ADO and then creates a new Pull Request to merge the changes into the "PR" branch.
At this point there will be no issue and the Pull Request will succeed.
- Developer A makes a change, commits their branch to ADO and creates a new Pull Request to merge the changes into the "PR" branch
- MERGE Conflict "checksum.txt" is different
The checksum.txt file changes after Developer B completed the pull request due to a new SHA1 calculation and their is no way to resolve this (well you could manually update the "PR" branch checksum file to be the new one, but... yeah, no don't do that).
At this point you might say, "Why not just pull down the latest "PR" branch into your Developer A branch and resolve the conflict there?" Well one, the checksum.txt is auto calculated and two, you can't. There isn't an option to merge one branch into another branch within Studio. Or is there...
Using Stashes
So ServiceNow provides you a way to store changes from one branch into a stash and then you can later apply that stash to another branch, so this is what we will do. Below shows the same scenario as above, but instead of committing the developer branch to source control, we take the following steps:
- Apply Changes to "PR" branch to get latest changes from ADO Git repo.
- Create a working branch from "PR" on PDI to make changes.
- Make changes on your branch
- When ready to commit your work, create a stash to merge into "PR" branch
- Switch to "PR" branch
- Apply stash changes
- Commit "PR" to ADO source control.
This will sync any changes beforehand and allow you to resolve conflicts in the ServiceNow Environment
Next up, releasing the changes to your Dev, Qa and Production Environments
Releasing Changes
Once you've got your changes into your Git repository, it's time to add some automated deployment steps to get your various ServiceNow environments updated.
Deploying to Dev
First, we'll update the ServiceNow Dev Instance by having users create a Pull Request from the "PR" branch into the Dev Branch. This shouldn't cause any merge issues since Dev will only ever get sync'd from PR within our DevOps environment.
Once the Pull Request is completed, an Azure Pipeline will be setup to automatically take those changes and deploy them to the ServiceNow Dev Instance. This is done by calling the CI/CD ServiceNow spoke, which is part of the Standard Integration Hub package, to do a "Apply Remote Changes".
Deploying to QA and Production
For our QA and Production deployments, we will utilize ServiceNow's App Repository. Using Azure Pipelines and Releases we will first tag a new release and make it available in the App Repository. From there, we'll have a Release triggered that will allow an approver to go into Azure DevOps and approve deployments to both QA and Production ServiceNow instances. This is all handled through the above mentioned CI/CD ServiceNow spoke by using the publish, tag and install endpoints.
