Should you create update sets within scoped applications?

Marco De Leona1 · ‎05-17-2018

When doing development on a scoped application, is it leading practice to create update sets for individual stories to track changes and help in code review? or should everything be done in the default update set? It seems like some things get excluded in the app updates when the code is captured in individual update sets.

Chuck Tomasi · ‎05-17-2018

Part of the beauty of scoped app is that you DON'T need update sets to move data between your instances. Use the Publish/Install feature and forget about it.

If you are providing this to another instance outside of your organization, then that's an exception because Publish only works between YOUR instances. If you were to ask for a copy of my Safety app that I wrote on my Personal Developer instance or another instance that I have to talks to our repo, the only way I can get that to you is to give you an update set.

I wouldn't bother using update sets in scoped apps. There's really no point. I would rather use source control to drop tags on the main branch to mark releases/sprints, etc. and then if needed, create a branch from that tag.

View solution in original post

Daniel Draes · ‎06-17-2021

Oh... relatively old post here. Our features have come a long way since then.

First of all, I would not recommend to mix deployment methods. In theory yes, you could deploy update sets to test and still push your code from dev to source control. If you forget to push an update set beforehand, your test will never recieve these changes. I would rather say rely on source control to get your changes to test. Start with a branching strategy and use pull requests to define when / what is deployed to your test environment.

I am happy to give you a hand on your first tests/trials here if you want. Can also do a demo how you can automate this today using our CI/CD spoke.

Troya1 · ‎06-17-2021

We are really just using SC as a backup of the application so only using a master branch.

What I'm trying to get at is.... what am I to do with the update sets from TEST when we are ready to deploy?

And if we import the app into PROD vs. using update sets, how does ServiceNow handle the custom app during a cloneback/upgrade?

Daniel Draes · ‎06-17-2021

Well, if you want to stick with update sets I would recommend to deploy to prod from your test system. This way you get exactly what was deployed there - lowest risk.

As for the cloneback question, there is only a difference if you install to prod via our Application Repository. This installation will mark the app as read only on your prod. On a clone to another system the clone engine will check if the application was already on that instance in 'edit' mode, if so it will retain it. Otherwise it will also be readonly on the target post clone.

Jochen Geist · ‎05-18-2018

I would disagree as well. There are a few reasons to still use Update Sets inside a scope:

Compliance reasons: Create a link between requirement and implementation
Peer/code reviews: Gets a lot easier when implementation is grouped in an Update Set
Update Sets capturing different objects than the scope: There have been a lot of fixes regarding this in the last releases but pre Kingston I would be very careful to just rely on the publish to Update Set option.
Minor updates: Deploy the change of a label as a single update inside an update set instead of publishing the whole app as an update set an then having to preview 4000 updates but only committing one change.

Due to the delete operations being ignore by the application repo, I would be very careful using the app repo. There are a lot of places inside the platform where deleting object is totally acceptable. To name a few:

Assigning roles to ACLs
Field maps in a transform map
Guided Tour Steps
Catalog Category Assignments
Service Portal Layouts / Widget placements

This makes working with the app repo very prone to errors.

Daniel Draes · ‎05-22-2018

Jochen is spot on.

My personal opinion on this: AppRepo is great for vendors wanting to put something in out store as it wraps the whole thing nicely. It does not serve well for in-house deployment as this has complete disjunct requirements.

On-top of the already mentioned:

- Deployment size/duration: The published update sets (which is what the scope does) tend to grow biiiig. Deployment takes ages to check all the changes.

- Important features like branching don't work - customers usually have something in production which needs some fixing while new functionality is being development at the same time (if you use branches it always removes the app before it applies another branch with the risk of data loss)

- At least until Kingston (not tested here yet) lots if 'buggy behaviour'. Some might be bugs (like layouts being destroyed), some intentional but bad (like deletions not captured) and so for.

- Global changes can not be included but are often required. How to make sure these get deployed in the same time - means customer needs to have two different processes active at one time. Not very logical and does not sound robust.

There is a long trail of internal discussion on this and we as ServiceNow need to find a good response on when to use what. But for now, I feel the best and most secure way is Update Set as it has always been 🙂