Should you create update sets within scoped applications?

[Marco De Leona1]

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.

[Dipu Joy]

The advantage of using a Scoped app is the instances will not have a residue on the application as they will not create any entries in sys_update_xml.

Organizations have different process in moving the stuffs around their instances.

Scoped app is a cleaner way to do it as its clean and anybody can update the app on the PROD instances and do not have to worry about the cumbersome update-set process

Using a scoped app, you can uninstall the application without any residue.

But uninstalling an app which was committed by update-set is not possible.

The actual issue arise when organization use Update-set and Publish/Install app together. 

If an app is published and downloaded and updated on an instance and if there were a modification which was committed in an update-set it works fine for the moment.

If the new version is published and have an update to the record which was moved in an update-set; it can create conflict issues because of the sys_update_xml entry. So these issues can be eliminated if we stick on with Scoped app Publish/Update process.

So both are good if the same option is used to move an application around.

If both options are used for the same application; it can create conflict issues.

Scoped app will not remove configuration if the new version have a DELETE in it. This is for the data integrity as any DELETE can be catroscophic and it is a assurance that data will not be manipulated with an app update. We can always Deactivate the configuration which should update that on the Target instance.

So to conclude, Scoped app Publish/Update feature is not messy and easy to implement as the repository manage the versioning for you.

Update-set can be  manual process with Implementation and with Version control.

Thanks,
Dipu Joy

[Daniel Draes]

Hi Dipu,

happy to have a more in-depth discussion with you on this, but at this point I cannot agree to most of your statements.

Scopes work ok if we talk about creating a brand new scoped application with the intent to offer/sell it through the ServiceNow store. But they to not work as a deployment mechanism for regular customers. Feel free to reach out to me internally.

Daniel

[jxsaxton421]

Hello,

I read your conversation and at my organization we use scoped apps frequently when starting a new project, depending on the project. When you say they don't work as a deployment mechanism? Could you elaborate? We use it heavily and I have tended to use both update sets and the app publish with pros and cons to each.

Thanks,

Joshua Saxton

[Daniel Draes]

Hi Joshua,

when you want to deploy you application for the first time the publish is a good feature. I kind of eleminiates the risk that somebody did create a configuration outside an update set (default for that scope) which you need to get the app working. So here I do not have concerns  have used it a few times myself.

Where I struggle is the maintenance going forward. Things I do not like on the publish feature for internal development:

• Delete oprations are not tracked
  Which makes sense for a store app, we don't want a store app do go havoc and delete customer data just due to a bad update, right?
  
  
• The publish will always contain all objects
  Depending what kind of app you build this can get pretty big. A deployment than takes quite some time even if you only did a few minor changes
  
  
• There is no preview
  The intention of apps is the app is always right - again, great feature for apps coming from the store. But if you run it internally you might have changes some things in your test or prod environment (I know you should not, but we all know real life, right?).
  
  
• Global objects anyhow need update sets
  With global objects still needed you suddenly have two different deployment mechanisms. If you have objects depending on each other it is not as easy to track the dependencies.

Hope that makes sense.

[scottl]

As a consultant working for multiple customers and their existing environments... Studio, scoped applications, updatesets and the mirgration to other instances have caused nothing but headaches. 

What I'd like to know is how many developers/consultants actually working in instances have the luxury of only working within only the scoped app they're building?  And from what I understand this "store" ability inwhich this whole scoped application was built for, is only avaliable to partners anyhow? Correct me if I'm wrong here.  And how many is that exactly vs everyone else having to deal with these scoping and update set issues in existing environments?

Maybe someone can shed some light also on why muitple update sets were created for all changes in different scoped applications?  Wouldn't it would have be easier for updates of ANY scope to go into one updateset?  Because if you were only building an app, it'll be in only one update set anyhow.  Because as it stands now with multiple scoped update sets, it's created so much overhead with no advantage and this is not mentioning all the issues above.  Because all one needed is to take the changes made, captured in an "update set" regardless of scope and migrate them into another instance.

Because source control in-which updatesets loosely match in functionally, cares not of the scope of the change unlike what the updatesets do now. And for what purpose? It's just more overhead esp. if the advised approach to publishing apps isn't robust enough, and one has to still use updatesets to migrate.

It was once, so much simplier.