RUG: DEV562: Safely Modifying a Packaged Application to allow Upgrade to Future Versions

NOT basic philosophy for upgrades: re-do all customizations for new version; Want to try and make it more automatic (or at least, as automatic as possible)
Automatic upgrades are possible, but there are some manual steps, and care must be taken.
The merge problem:

 * original app -> vendor new version ->
                |-> my updates to app -> NEW MERGED VERSION

• How do you make it so that to independent teams making changes, don't conflict with each other?

What do you need to do?

• Decide whether modification is really needed?
• Keep an eye on where development is going (vender and internal)
• Plan and follow process during upgrade
• Test and resolve conflicts

Modification needed?

• Important to the business, or just legacy?
• Is it an add-on or built-in to the application?
• Add-ons generally safe, built-in is intrinsic to application, much trickier

Where is vendor going?

• Know vision and direction of the application supplier
• consider the philosophy of the application
• more likely to be compatible as upgrades happen

Where are you going internally?

• Develop a vision and direction around the application

3 simple rules to follow when making updates

• Do not repurpose fields (OK to add fields; OK to use existing fields for intended purpose; DON'T arbitrarily re-purpose fields)
• Do not change existing workflow (OK to add workflow; OK to copy existing workflow and change the copy [pick different name prefix]; OK to disable existing workflow [upgrade will re-enable] - only change allowed
• Do not change permissions (Add new groups/permissions, don't touch BMC's)

BMC Commitment (fields)

• All fields and VUIs of BMC forms will have IDS in reserved range
• During upgrade, will not modify or delete any field that is not a BMC field
• BMC is free to change definitions of fields they own (OK to add new groups and permissions; don't modify perms on BMC's groups)

BMC Commitment (workflow)

• During upgrade will not modify or delete any workflow that is not BMC's
• BMC free to modify its own workflow in existing way

Make backups first

• generate an export file of all definitions in the AR system server
• can also backup at database level

"ardisabled" utility

• Available from developer site
• makes list of all disabled workflow (will need later)
• Helps you find what needs to be re-disabled after upgrade
• Run in import mode to do re-disabling for you

"arpermission" utility

• records all permissions for your groups
• creates a file containing a list of all workflow/fields/forms in the system and the permissions assigned for specific groups
• developer community (soon)

After upgrade

• Restore disabled forms and permissions
• Restore views (which were exported before-hand) -- note that new fields will not show on view, and will have to be added manually
• History/change data will be preserved

post-upgrade manual work

• direct modifications to factory definitions, make again
• modified qualifications of any application table fields need to be restored

testing

• you need to run a suite of tests for the application after the upgrade