GitHub Integrations

[Ross Drew]

Our organization would to connect with GitHub to be our source control and use it to move updates across the DEV, TEST, SANDBOX and PROD. However, I see that GitHub works fine with scope apps, but not really with Global updates. Furthermore, I see that a recommendation is to create a psuedo of the Global app, but my concern is upgrading. How is that impacted? Has anyone come up with a resolution to this issue? I have been searching the community and have not come across any articles that provide a resolution. Also, I would thankful if someone can point me to an article/s that really explains how to properly set up source control (preference is GitHub, but are there other tools) with ServiceNow.

[Tanushree Maiti]

Hi @Ross Drew 

Generally we follow 

Update Source

Source Control ( only for scopped app) to move update set to other instance.

According to me , the concept that building a "pseudo-Global" application in ServiceNow is simply generating technical debt which involve huge customization which is not recommended .

It defeats the purpose of the platform's modern architecture. It introduces unnecessary risk and customization that goes against best practices.

Refer following videos:

How using source control->github, update set of scoped app gets moved to other instance:

https://www.youtube.com/watch?v=YSrP9qGsoh8

https://www.youtube.com/watch?v=pct5iyXhnQc&t=16s

Also check:

https://www.servicenow.com/community/developer-forum/will-github-replace-update-sets/m-p/1605636

[Ross Drew]

ChatGPT suggests a hybrid model.....create a new custom application scope for any new work....and for existing objects use update sets to capture the updates and export the update set in XML to the GitHub repository. Have heard this before?

[Tanushree Maiti]

Hi @Ross Drew 

"create a new custom application scope for any new work." - My opinion differs a bit here.

Building a custom application scope is the absolute best practice recommended by ServiceNow for any brand-new business tool or standalone application. It isolates your code, secures your data, and makes deployments seamless.  

However, if you are simply making standard customizations to OOB modules (like standard Incident, Problem, or Change tables), a new scope is not required and you should stick to Global. 

[Ross Drew]

And in this instance "However, if you are simply making standard customizations to OOB modules (like standard Incident, Problem, or Change tables), a new scope is not required and you should stick to Global." we would want to capture those changes in an update set and then export them to GitHub for source control, review and deployment to other instances. Does that sound like a workable solution that does not create drift or other problems?