Plan the update process for an Update Sets

Because update sets make changes to an instance, review the following best practice information to avoid errors and performance issues. Learn how to plan the update process to ensure that there are no problems during the process.

About this task

Before working with Update Sets, create a standard process for moving customizations from instance to instance.

Procedure

  1. Check that both instances are the same version.

    Customizations may not work if they rely on code that has changed between versions.

  2. Determine the changes to make in a single Update Set.
    Complete your update sets as you finish small to medium-sized tasks. As update sets get larger, it becomes harder to review them, takes longer to identify specific changes within them, increases the risk of conflicts with other update sets, and takes more time to preview and commit them. This is especially true if the update sets contain schema changes or revisions to large workflows or if the set has to be backed out.
  3. Ensure that all base system records have matching sys_id fields.
    Some base system records are created on an instance after provisioning and do not match between different instances, leading to problems with Update Sets. The best way to avoid this issue is to:
    • Provision production and sub-production instances.
    • Clone the production instance onto the sub-production instance.
  4. Identify a common path for Update Sets to move from instance to instance and maintain that model.
    Never migrate the same Update Set from multiple sources. Best practice is to move Update Sets from dev to test and then from test to production.
  5. Plan for when to commit the Update Set to production.
    Avoid committing an Update Set to a production instance during business hours. The instance may perform slower temporarily as the Update Set applies.
  6. Make sure Update Set names are clear.
    Create a naming convention to coordinate changes from multiple developers and to reference when committing the changes to another instance.
    • If Update Sets are being generated as fixes for problems, consider including the problem ticket in the name (for example, PR10005 - Duplicate Email Issues Fix).
    • If you need more than one Update Set to address a problem, include a sequence number in the naming convention so that Update Sets are applied in the order that they were created (for example, PR10005 - Duplicate Email Issues Fix and PR10005.2 - Duplicate Email Issues Fix).
  7. Know how Update Sets work.
    • What records are generated for an Update Set
    • Which customizations are tracked by Update Sets
    • Which dictionary changes are valid for Update Sets
    • Which customizations can be backed out (reversed) once applied
  8. Before making any customizations, double-check that the correct Update Set is selected.