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

Chuck Tomasi · ‎01-10-2020

I invite you to watch episode 71 of TechNow (recorded Dec 2019) which answers a lot of these questions.

TechNow Episode List

scottl · ‎01-12-2020

Thanks Chuck, I watched the video however it doesn't cover any of the actual issues raised in the above posts. This video only reinforces the "I'm only ever creating and changing one app".

Now try modifying the "Now Mobile App". I've had to reinstall my dev environment for a third time now due to the mess in the scoping, and that's if Studio doesn't corrupt it's forms thus wrecking the App header. Even in one of the SN mobile app support videos Studio failed to work correctly. That was quickly glossed over, as the video moved onto another instance.

The inconsistencies in direction for migration, esp. for this mobile app, proves these points and after doing all these changes what effect does this have on "upgrades" in these OOTB scoped apps esp. the Now Mobile App, as one is having to modify the OOTB application directly and not in Studio, again contradicting the scoped application migration through Studio and now having at least 6 update sets to migrate, and should I be even "publishing", if I even can, an OOTB application (publish restricted in dev instances)? I won't even begin to ask why "Mobile Agent" is in the Global scope.

It's an absolute mess from my stand point and not clear at all, and with these Studio defects it isn't helping either because if I'm having this much of an issue in a fresh dev environment, I'm seriously hesitant about doing this in a customer's environment, and one that doesn't use source control.

And I've also noticed that source control in Studio, when pushing to the repo, deletes the updated records from the scoped application update set. Now this maybe as expected but I'm not sure how this helps anyone esp. when it's stated "we shouldn't be deleting anything", inwhich Studio M.O. clearly stands by yet goes about and deletes all your changes.

And how does all this work with multiple custom update sets in a custom scoped application, which updateset gets published when using Studio, and source control isn't setup?

Chuck Tomasi · ‎01-13-2020

This is a fairly large discussion to have - one that goes a bit beyond a response in a two year old thread. I suggest two options.

Option a) Start a new thread in the developer community and allow others to contribute their thoughts to crowd source a solution. A new post will increase the visibility.

Option b) reach out to a ServiceNow Solution Consultant and get some one-on-one time to discuss your best approach.