Upgrade Best Practice Question: Conflicting code

[toneyvecchio1]

Greetings, I am preparing for a Helsinki upgrade from Fuji in dev - I am currently stepping through the upgrade history and code that was skipped. I am entering comments in the upgrade history conflict record, making my merge/replace/retain decisions while capturing my sessions in an update set.

My question is, what is the best practice to re-deploy these efforts when upgrading test/prod. The same conflicts will occur, do I push my "patch" update set? That will probably fix most of the merge/replace I assume. I also imagine that the upgrade history will not have any of my notes or resolution statements however.

What is the best practice on these types? I've looked at the wiki Best Practices and it does suggest to do what I am doing but doesn't discuss best practice of moving that effort into high-level instances.

[The SN Nerd]

You're definitely on the right track.

We have done all our upgrades using a similar approach.

[toneyvecchio1]

So when you finish doing this dev, and then you upgrade test/prod I take it you move your update set over. However your production upgrade log would, I assume, still show all of the conflicts and you would lose the "Reviewed and Merged" and "comments" fields, correct? Or do you track your changes externally?

To me, it almost seems like it would have to be: Apply upgrade, apply update set, re-apply upgrade (like Preview again on update sets) so that the system recognizes the update conflicts have been managed, or redo it all manually? Once I clone over dev I lose all the real logs of how I handled my upgrades.

I recognize that I am focusing on something that only impacts up upgrade conflict checks and not the actual code which is fine through update sets, but when I clone all down and step through the conflicts down the road it would still show all these - or is my assumptions incorrect?

[simonw]

Hi Toney,

I went through a similar process from Calgary to Fuji recently and realised some 100 or so items needed restoring to OTB.   My work flow was to review the skipped updates and revert if necessary, or capture actual updates to an update set as you have done.   You can't capture the revert to OTB in an update set as that would itself cause the item to be customer modified and thus skipped.

This next bit sounds ridiculous, but the same process needs to be repeated on test and prod, depending on how close your instances are customisation wise.   So I filtered all reverted items from the sys_upgrade_history table on dev, exported the filenames (which are consistent between instances) to a text file and created a query I could run on test & prod which showed the file was not reverted where the filename was one of those I wanted to revert.   Then it was just a manual churn exercise to revert them with a few hundred clicks.   The upgrade process then became allow the platform update to finish, deploy my update sets then work through the report reverting each update I wanted to restore, it ended up just being an exercise in clicking.

Any actual conflicts in your update set still need to be previewed and assessed manually during the upgrade, but in theory you should only get those if items are newer on your test or prod instances which shouldn't be the case.  

In hindsight I could have gone through assets before the upgrade and mark as Replace on Upgrade - but that is quite fragmented as you'd have to jump between different types of record.

Kind regards,

Simon

[toneyvecchio1]

Simon thank you for that clarification - that's pretty much what I was thinking I would have to do to get to desired state and really good to know the accept OOB are not captured.

That makes it a bit of a bear for deployment but I can somewhat see why its that way. Glad to know that OOB piece and that I am not missing something much easier!