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.

[simonw]

Remember you only have to revert on this upgrade (on each instance), unless you customise the scripts they'll be out the box for the next upgrade so will be handled automatically.  

It's a painful process, but equally its a very good reminder why we shouldn't change out the box items

[chris_f]

Just a heads up, since Geneva, if you revert to OOB during an upgrade (Say Fuji to Geneva) the reverts ARE captured in any update set.

So you can do all your reverts etc, then upgrade prod and apply that update set from dev/uat (Wherever it was you created it).

[lss123]

Toney, how did you end up dealing with the upgrade history logs on Test and Production?   After applying the upgrade, did you have to manually review and change the status of each skipped update?

[toneyvecchio1]

Yep - I ended up just re-doing it in Prod (didn't spend time notating in Test). Also thought about making a transform map and export/import my log between instances but I didn't want to see how that worked out relative to the time frames I had in front of me.