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.

[Chuck Tomasi · Accepted solution]

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.

[Marco De Leona1]

Thanks Chuck, this was helpful. We'll have to figure out a way of tracking development in other ways. It would be great to use source control but not all of our clients have that as an option.

[LRadtke]

Hi Chuck,

I am a bit ignorant here, but what if you didn't know any better at the time and installed a Scoped App via Local Update Sets.  Now, in our higher instances, the apps show as still in development.

My question, is there any way to migrate that over to have it installed from the App Repo?

Thanks!

[Daniel Draes]

I am actually not in full agreement to Chuck here ... sorry mate 🙂

I have used the publish feature a few times and at least in my experience it does have some problem still. I would therefor recommend to stick with update sets as we did in the past. This is most reliable.