When using update sets, there are some best practices we can adhere to to ensure we avoid adding bad customizations to our production instance and use update sets to their full potential.

Firstly, it is always a good idea to check the updates contained in your update set before completing it. Sometimes a developer can inadvertently add an update they did not mean to to their update set. Therefore, it is always a good idea to check each individual update contained in your update set. In particular, pay special attention to any updates where the action is DELETE, as this can be harder to undo.

We can see some example updates in an update set in Figure 11.6:

We can see the updates in this update set in the Customer Updates tab of the related lists. We can see three updates in the update set example, including two client scripts and a business rule. We need to ensure that every customer update we see is a change we want to include in this update set, and no additional updates have been included in this update set by mistake.  

In the Action column, the action that will be taken when this update set is committed is shown. Of the three updates, we want to pay special attention to the one with the DELETE action to ensure this action does indeed need to be taken. Once a record is deleted, it can be more difficult to undo the action. An insert or update is a much easier update to change or revert to an earlier version.

It is also a good idea to have a naming convention for your update sets. At first ,when update sets are small in number, this seems unnecessary; but as an instance matures and the number of update sets grows, it can be extremely helpful. The naming convention does not need to be complex, just consistent. Common naming conventions can be for releases, sprints, or the record number of stories or defects.

Some examples of naming conventions are:

• Description - Release - Date
• Story/Defect: Developer
• Sprint/Month

When deciding on a naming convention, decide on the details that are relevant for your process and instance, and make sure the convention is adhered to.

As we saw earlier in this chapter, when setting up an update source, we need to provide a username and password for an admin account for the instance we are taking update sets from. It is good practice to ensure the account details used for the update source are for an account that will not be amended frequently, as this will stop the update source from being able to pull update sets from that instance.

With update sets, it is good practice to ensure that update sets being committed in a production instance are done so at an appropriate time. As with any change to a production system, there is a level of risk associated. This means committing update sets should be done outside of business hours if possible, or at least at a quiet period of time, in case any problems arise.