- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-17-2018 06:44 AM
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.
Solved! Go to Solution.
- Labels:
-
Best Practices
-
Scoped App Development
- 9,748 Views
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-17-2018 06:49 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-17-2018 09:04 AM
That was my initial feeling, since we're on Kingston now I'm hoping that the wrinkles have been ironed out.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-17-2018 12:54 PM
What issues are you experiencing?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-17-2018 04:06 PM
Our dev team had been capturing all of the scoped work in individual update sets so that we could map them to our stories, when we published the app and installed it in our Test environment there were a lot of updates that were missed and didn't carry over. What we had to do to resolve the issue was to merge all of the scoped update sets and commit the merged update set to our Test environment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-18-2018 05:14 AM
A good point. Most notably, DELETE operations are not carried over. The biggest trouble with this seems to be around choice list modifications. The original reason is so ISVs don't start removing tables, fields, properties, from your app that other apps may be depending on. Our platform business unit tells me that this is being addressed in an upcoming release (London perhaps)?
If you are on Kingston or later, take a look at Update Set Batching rather than merging, should you choose to continue with them. It makes it easier to backout a specific branch of the tree or single update set if needed. Something not possible with merged update sets.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-16-2021 03:03 PM
Can we do both?
We have DEV, TEST, and PROD environments.
Commit changes via update sets to TEST, then commit changes from DEV to Source Control (update set is deleted).
This is my first time using Source Control but want to make sure that the application is secure during clone backs and upgrades.
