Deploying changes with change sets

In the previous section, we talked about the metadata changes that are deployed into a chain of sandboxes until the final production release.

There are different ways to achieve a metadata deployment:

• Metadata SOAP APIs (refer to https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_intro.htm for more information)
• The ANT Migration Tool (sometimes called the Force.com Migration tool—https://developer.salesforce.com/docs/atlas.en-us.218.0.daas.meta/daas/meta_development.htm)
• An IDE, such as Visual Studio Code (https://forcedotcom.github.io/salesforcedx-vscode/) or other popular IDEs
• Packages
• Change sets

Unlike change sets and packages, the other ways require you to master a developer’s attitude. Let’s start with change sets.

Change sets is a powerful feature that’s meant to help administrators and developers easily deploy metadata from sandbox to sandbox, or from sandbox to production, using a point and click approach.

The following steps are required to unleash change sets:

1. Create an outbound change set on the source organization.
2. Add the changed metadata items to the change set.
3. Upload the change set to an enabled destination organization.
4. Validate the inbound change set on the destination organization.
5. Deploy the change set on the destination organization.
6. Monitor the deployment.

Repeat until you have all green lights!

The first thing you need to set up is a deployment connection between the organizations you want to move metadata between. A source organization creates an outbound change set that, while uploaded, becomes an inbound change set on the destination organization.

You can only connect organizations affiliated to a production organization, which means you cannot move metadata using change sets from a Developer Edition organization to a sandbox or production organization. Change sets are enabled only between sandboxes and their production organization.

A connection should also be authorized to send and receive change sets, thus enforcing security on change promotion.

Typically, production will receive changes only when tested and approved. This means we’ll have an incoming connection from the UAT sandbox, while Dev and UAT may have a two-side connection because Dev can deploy to UAT. After testing and typically small configuration changes, UAT can bring those changes back to DEV. As we saw in the sandbox architecture earlier, your company may have this particular set of deployment connections.

The following diagram illustrates how connections can be established inside our architecture (as shown in the previous section):

Change set direction on each sandbox

Note that after UAT, the changes only go forward. This may be a requirement of your release management team. Metadata should only be changed until UAT, which becomes the final source of truth for metadata.

There’s no one-size-fits-all solution. Design your sandbox structure based on your needs and on your company’s policies.

To enable a connection, go to Setup | Environments | Deploy | Deployment Settings:

From the list of all your active sandboxes (and production, if you are running the tool in a sandbox), choose a sandbox that you want to establish a connection with by clicking on the Edit link:

You can enable inbound change sets coming from the selected organization and see if the given organization is accepting inbound change sets from the current organization.

Take a look at the following screenshot:

Here, we can see that the Production organization can receive inbound change sets from UAT, while UAT has not yet authorized Production to send its outbound change sets (Accept Outbound Changes is not flagged).

You will see the following screen on the UAT sandbox after configuring some deployment connections. It can deploy to production and accepts deployments from QA.

Once the connections are created, on the source organization, navigate to Setup | Environments | Outbound Change Sets, click on the New button, and fill in the Name and Description fields:

As shown in the previous screenshot, to add a new item, click on the Add button in the Change Set Components section, choose the component type, and select the changed components. Also, click on Add To Change Set to complete the change set’s creation:

This will open the following view:

In this example, we have changed some stuff:

• A new custom field on the Lead object
• Lead page layout to include the new field
• Two workflow rules that trigger the new field’s values
• Two field updates that set the new values on the field according to workflow rules

Not every metadata type is available on change sets. For a comprehensive list, refer to the official documentation at https://help.salesforce.com/articleView?id=changesets_about_components.htm&type=5.