Reverting to baseline and update sets

[akaupisch]

We are upgrading from London to Madrid. We have an upgrade environment which is a clone of our production environment. I am going through the Skipped Changes to Review related list off the Upgrade History. Some of these changes I simply want to revert to baseline, and do so prior to the upgrade, so it can be properly tested. So here's the question:

If I revert something to baseline and it is captured in an update set, when I apply that update set to other environments, prior to the upgrade, will that flag the reverted file as modified or will it actually revert everything properly?

i.e. I'm wanting to fix everything in the upgrade environment and then apply it to prod prior to the upgrade, thus skipping the repetitive steps of reverting it after prod is upgraded to madrid.

[ARG645]

If you revert an item through updatesets/Manual before the upgrade, then after the upgrade your item will still appear in the skipped items list but upgrade is smart enough to exclude it from Skipped item to review list. These is a field called ‘Changed’ , if upgrade finds no difference between the versions then it will mark it as Changed = false, so that you don’t have to review it !!

[akaupisch]

is there any easy way to remove the changed field after the update has been committed? That way we can get back to baseline and not have to worry about this again? if we remove those files from the sys_update_xml table will that fix it?

Update: For sake of an example. Say there is a notification that was updated. I revert to base after the upgrade. Now, say in New York they make a change to that notification. Will it prompt me to review it at that time since the file was 'skipped'? 

What I'm trying to avoid is reverting to base now, then getting stuck with a madrid base and having to go through all this again in Paris or whatever in the future for the same file.

[Luis Franco]

Hi.

We've just completed the upgrade from Kingston to Madrid, and we had to deal with the items that we had Reverted to base during the upgrade to Kingston from Istanbul... This happened only on the records that had the flag changed=true from kingston to Madrid.

The easy way to decide on these issues was seeing the sys_updated_by value on the record to check if we had done any change over the OOTB. We can do this because we don't use the default admin account in our instances. It was only used to create the individual admin accounts.

What we tried to do to save us some time was to create an import set to update the comments on the production instance, with the issues we had solved in development. But we were only partially successfull. For some reason more than 70% of the comments we had to reinstate manually.

The issue there is the coalesce key. We believe it is not enough to have the file_name has key because some of the file_name do not include sys_id.  

Then we turned to disposition column on top of the file_name. But we also found that the disposition is a bad key because after you decide on development, the disposition changes also. 

Fyi, what we had on our plan to production was:

- Clone to development / upgrade development / Prepare update sets

After thorough testing and planning the communication plans, etc:

- Upgrade production

- activate plugins if needed

- Preview of the update sets that we have prepared and solve any problems so that they can be committed.

- Update the skipped upgrade issues with the comments and state (merged, revert to base, etc) from development.

- Check the skippd upgrade issues that didn't exist in development. Hopefully they are not many because we did the clone to development prior to the upgrade.

- Commit the upgrade update sets that we had prepare.

Hope this helps.

Best regards,

Luis Franco