Deployments in ServiceNow

 

Managing your Deployments in ServiceNow

Intro

These are my notes from this tutorial.

Application components and scopes

All these building blocks for all ServiceNow applications can be updated/upgraded/changed and deployed to a remote repository via source control.

Application Scoping

Application Scoping Model

Collecting application files together in "walled gardens".

Note: to troubleshoot an instance use Instance Troubleshooter app. For more info, check out this tutorial.

Global App Bundles

Not the same as scoped apps

• Not the same as scoped apps
• Logical grouping of GLOBAL scoped application files
• Allows use of Studio and its feature set
• Not a 'walled garden' of protection like a true scope
• It doesn’t have the same security features like a scoped app
• Which means you cannot designate other developers/collaborators to work on the global app bundles like in a scoped app
• Can utilize Source Control and Application Repository

Application Customizations

Encapsulating application customizations

• Bundles customizations to a store/plugin based scoped application
• New application files and customizing existing app files
• Can utilize Source Control and Application Repository

Deployment Methods

Update Sets

Can update sets be used to move initial configurations/implementations for plugins between instances? Example: Install and configure Service Graph Connector for SolarWinds on all instances.

You can package up configurations for plugins between instances. But you do have to activate the plugin in each instance before applying the update set with the configuration updates.

Source Control

Note: one branch per app per instance!

Note: it’s a whole cultural and org shift and you need to know Git!

Application Repository

Note: it’s a SN app

So, which one method does SN recommend?

It depends! Default: update sets

Deployment Strategies and Architecture

Update Sets

It’s a straightforward pipeline.

Batching vs Merging

• Batching is stacking update sets within a batch/parent update set.
• Merging: merging update sets into one update set.

TIP

After you get up to PROD and after the change window is closed, go to your local update sets and mark them all as ignored. That way when you do your clone in the sub-prod instances, it looks like there’s no open update sets. Everything is just cleaned up to ignore. Then when you get to the next promotion of the PROD, it’s really easy to see how many batches and update sets have been imported.

Source Control

Here we have a four-stack: two DEV instances and one PROD and TEST instances. Additionally, we have new features (branches) off the main/master branch. As you can see, feature B is committed before feature A. Rebasing is done after the merge. Make sure that the branches are in sync.

Application Repository

This is a simple outline of the app repo. Via the app repo you have access to any app associated with your company. For example, if you have more than one PROD instance in the same company then those instances have access to the app. So, first you commit, then publish the app repo and lastly announce the release of the new version.

Source Control and Application Repository

Hybrid approach

The reason for the hybrid approach is for the selective publishing. You want to do selective publishing to a certain point. So, you start with Source Control approach. From there you want to say, is this PROD ready? If it is, then you can switch to the App Repo approach and to deploy the applications.

Decision for App Deployment method

Can I use source control?

Resources slide

Tech Papers

• ServiceNow Development Pipeline Management Guide
• Developing in the Global Scope Guide

Videos

• Update Set Automation via IntegrationHub - Live Coding Happy Hour
• Automate your ServiceNow CI/CD pipeline
• Setting up your first CI/CD pipeline with GitLab CI/CD Pipelines
• Setting up your first CI/CD pipeline with GitHub Actions

Documentation

• CI/CD APIs