- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-15-2016 10:39 AM
After I resolve all conflicts in the Dev environment, and I go to upgrade Test, all of those conflicts will be there. Do my conflict resolutions in Dev get captured in an update set, that I'd move to Test? In Test, do I need to manually review each conflict and change its status?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-15-2016 11:10 AM
That is correct. It is a manual action for which I also looking for some workaround.
I know it's a pain, as for me the records that needs this manual action is around 600
I have already to capture the changes via an update set and apply it, but it doesn't work either.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-15-2016 11:28 AM
If fixes are captured for merges, those got applied properly but fixes for reverting codes did not apply (Reverting to OOB).
So if you have merged the changes, then you should be good to apply those. And yes, updating the status is a manual effort.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-16-2016 06:12 AM
I'm noticing that as I go through all of my upgrade conflicts, I always keep the customized version. Is there any case where we wouldn't? How often do you find you're actually merging code or reverting to the OOB version?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-16-2016 10:39 AM
It depends actually and varies case to case.
What would be the cost of maintaining the customised code?
Is there any feature in the update one that you wish to leverage?
What would be the level of effort required to fix the issue if the upgrade has broken your customization?
What could be potential future impact of maintaining your customization?
These are some of the basic questions that you need to ask yourself. It is always very enticing to not touch anything that already works and ignore it. But I prefer keeping an eye on future. What can we expect on future releases?
Let me give an example of what I mean.
We had a heavily customised version of catalog and cart logic. The upgrade has broken it down completely and fixing it during the upgrade cycle didn't make sense. We evaluated the cost/effort of maintaining the customised code and decided it would be better to switch OOB. With ServiceNow going away from Jelly and Service portal in mix, it just didn't make sense to keep going with our customization.
Yes, we had to sacrifice a bit of our customization for now but the potential benefits that we would have in future weighs far more. Also, having a good business partner (BA's) who understands the environment would be a huge plus when driving such things as you may need to sacrifice some things when reverting the customizations.
Hope I didn't bore you out with a long response and you found it relevant
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-17-2016 05:48 AM
That was very helpful, thanks. I appreciate the insight.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-15-2016 11:35 AM
Our team had the same question.
It would make perfect sense to have developer notes persist with certain modifications which were deamed, 'Resolved, keeping modified copy'.
That way in future upgrades the new colision results might show a previous developer's justification.. which may ease the process of merging or restoring.
In the end, we chose to filter our worknotes for these select items and export a PDF/Excell to our KB for future reference. All of our restorations and merges were tracked into a single update set which was applied in Production just prior to upgrade.
Best of Luck,
