Inspired by Chairng Lin’s you tube video on ServiceNow CICD for GitLab (brought to my attention by a co-worker) and the tech industry push for DevSecOps (and at the request of one of my clients), I attempted to replicate CI/CD automated code promotion using GitLab for ServiceNow update sets. Many of the clients I work with have multiple PaaS platforms including ServiceNow (I know, they don’t know that ServiceNow really is the best and spend money on ‘others’), and they are looking for tech solutions where a centralized governance team could have a common approach to DevSecOps that could be leveraged for all the PasS solutions, not just ServiceNow.

OPTION RESEARCH

I started with researching ServiceNow capabilities, given the constant innovations published with each new ServiceNow release that are both awesome, but also at times challenging. As a ServiceNow Solution Architect, I have to continuously re-acquaint myself with the latest and greatest features and capabilities that ServiceNow has delivered. I found what I thought were 3 potential options (there ended up being two) for automated code promotion, highlighted in ServiceNow documentation:

I opted to not use the new ServiceNow AES (app engine studio) CI/CD functionality, frankly because I have not yet found a use case where as a ServiceNow platform governance team architect lead, I would ever allow a citizen developer or junior developer to promote code. To me, this would introduce an unacceptable amount of risk that could very likely tie up my most senior devs to develop and implement a hot fix into production as quickly as possible.

THE JOURNEY

Before I worked on setting up the GitLab ServiceNow CI/CD solution, I did watch Chairng’s you tube video a few times and took careful step by step notes. Then I decided to implement. As I worked through the process, I found details not specified in Chairng’s video were important and figuring them out was not intuitive. I had to roll up sleeves and after a few successes with many missing configurations, I called for backup. After all, 2 big ServiceNow brains are always better than one! I collaborated with Thomas Stroffolino (ServiceNow Partner Technology Strategist) and we worked through each of these ‘gotchas’ to finally get a working solution. It took us a couple of weeks but we finally did get through each issue and had a working solution!

WHAT’S NEXT

Now, I of course, find myself thinking of you all, my fellow ServiceNow implementers and developers, and in hope of saving you all for some of the pain Thomas and I endured, here is what I hope are some helpful lessons learned. Thomas and I also collaborated to bring this information to you.

Unfortunately, neither of us will be able to provide any troubleshooting assistance to any of you who might encounter issues in setting up your own ServiceNow GitLab CI/CD, but I believe in you!

Happy Coding and remember to STAY INNOVATIVE!

SERVICENOW Environment: Instance Usage and Configuration LESSONS LEARNED:

• You will need a minimum of three instances to configure this demonstration.
  1- Dev, 1- Test, 1- Prod
• Partner Demo Instances or True Sub-Prod instances associated with an account are required.
• Do not use ServiceNow Personal Developer Instances nor ServiceNow internal employee Demo Instances for this CICD functionality. The lack of a connected ServiceNow My Company App Repo will prevent the pipeline from running properly.
• If you must use ServiceNow Instances, you will need to configure your own My Application Store on a separate instance and point your instances to instances. Guidance on how to configure this instance is in the appendix of this deck here and will require a separate instance.
• You can confirm the connectivity of your instances to the My Company App Repo by looking at the system property sn_appclient.repository_base_url under

SERVICENOW Additional LESSONS LEARNED:

• When going into studio to create a new branch, first always 'Apply Remote Changes'
• When you create a new branch in studio, a new update set will automatically be created for you and set to current
• When you first connect your application to GitLab, even though the GitLab default branch is ‘Main’, ServiceNow will overwrite this to ‘Master’
• Make sure you Test Suite will run and pass in the ‘test’ instance it will be run in
• When creating a user profile in ServiceNow that GitLab will use to log into each of your ServiceNow instances, be sure the user profile:
• Has the web service access only checkbox checked and the sn_appclient.app_client_user role
• The password does not contain a ‘$’ (GitLab will not read the password correctly if there is a ‘$’ sign in the password)
• Make sure there is a user profile in each of your ServiceNow instances for GitLab to log into each one
• We were able to successfully run the pipeline of San Diego and Rome instances. These recent release ‘dev’, ‘test’ and ‘prod’ instances did not all have to be the same release.
• System Properties  All Properties. It should point to https://apprepo.service-now.com/

GITLAB LESSONS LEARNED:

• When you create your project in GitLab, unselect the ‘Initialize repository with a README’ option. This option will automatically create a ‘main’ branch for your repository and ServiceNow will create a ‘master’ branch. The pipeline will not run properly with both branches.
• In GitLab, under Settings -> Tokens, create a Token with Maintenance role, and all permissions. Use this token (write it down!!) as your password for a Basic Auth credential you create in ServiceNow. You GitLab username will be the credential user name. This is how ServiceNow will connect to the GitLab repository.
• When creating your authentication variables, use the user profile you created in ServiceNow with ‘username:password’ syntax.

.YML FILE LESSONS LEARNED:

• Recommend changing AppPublish stage VERSIONFORMAT from autodetect to template and add a template variable of ‘1.0’
  
  • VERSIONFORMAT: "template"
    
  • TEMPLATE: "1.0"
• .yml is a serialization language, similar to JSON. We found a couple of great You Tube tutorial videos here and here.
• Spacing in .yml matters

Labels:

• Integrations
• Scripting and Coding
• Studio