Global Scope Applications and Source Control

[qsanchez]

Hello,

I want to use source control for ITSM and other global scoped application customizations.

In order to do that, I create an application in Studio and add the needed files.

What do you think it is the best approach to define this application/s in Studio?

I mean, defining only one big application with all global customized items? or splitting it in some applications like ITSM, CSM, ...? or maybe divide it in another way?

Thank you very much in advance!

[Miguel Donayre · Accepted solution]

HI,

This ultimately depends on the way your dev team handles work.

With that said, you can break it up so that you can have a repo set up in your Git repository for each developer, a certain aspect in ITSM like one for Change forms, Change Business rules, etc., or however you want to break up with for your team where it is effective of managing. 

If you are using Source Control, the key here is to break up a big global app to have the freedom to get away from the "One branch per application per instance" using source control. Remember that you will still require a repo in the Git repository for each Global App Bundle if you use Source Control.

The beauty of using a Global App Bundle is the ability to "claim" different objects into another Global App Bundle. So if one approach, for example, if you use one Global App Bundle per developer, is not working out. You can restructure to something like a Business Rule Global app bundle and claim all business rules from the old Developer Global Apps Bundle into the new Business Rule Global App Bundle. 

I have seen where they have it broken down by a developer global app bundle and where it is broken out per functionality inside a product like forms, tables, scripts, etc. It comes down to your choice of managing the changes on the platform. 

[Adam43]

we do a LOT of catalog item work.  does anyone have recommendations around breaking that up?  we do revisions to the same hi-use items, have less than a dozen devs who do all the flow design and item maintenance.   Up to now we've been using update sets and remote instance pulls to move from Dev to our Test instance for individual batches as read (batches are distinct per Agile story- and catalog items are always separate in stories- we don't put more than one item in a story).  once UAT process is complete (ATF built and user acceptance testing is finished, then we're ready for the prod release) we batch all of these together into one master Release batch for moving to Prod.  It's worked pretty well for us, but lately we've had some other work going on that involves a lot of data work interspersed with the update sets- ie. fix scripts that need run after 2 update sets, then more update sets and another fix script to populate data somewhere etc.  this causes a runbook release to prod that is way more time involved and complex than our standard One Master Batch release.

Hoping App Repo can help with this.  question- would we still use udpate sets to track the work and those get captured in the app repo too?

[Brady Holliday]

Hey @Adam43, 

Using source control changes how update sets are utilized. When you commit up to source control, you lose the ability to move those updates up through the remote instance pull that was previously used. Instead those updates are committed to Source Control and you have to shift to managing branches instead of update sets.

What we have done is tied our DEV and TEST instances to dev and test branches. We then utilize automation to cherry pick the specific commit (based on a WIP ID that was submitted with the commit) up to the test branch. We then utilize a production branch by doing the same thing to move a commit from the test branch to the production branch. The catch here is that in order to still install custom apps from the ServiceNow Store, we have to switch the TEST instance to the production branch and then publish while TEST is configured with the production branch (essentially to ensure no updates are pushed to PROD that haven't completed UAT). While this may not be the ideal approach, it has allowed us to conform to a more standard development cycle that is not specific to ServiceNow development.

All in all, update sets could still be utilized to some degree, but keep in mind, when you commit to source control, the updates within that update set will no longer exist post-commit as those records have been committed to the external repo. (So, if you are just starting to implement the source control setup, maybe export out the update set prior to committing to the repo so you have a backup, just in case you decide to revert to deploying via an update set instead managing source control branches).