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.

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):

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.

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

Did we forget something? Let's say that everything has been set up (although it hasn't—don't worry, we'll understand why shortly).

Click on the Upload button to send the change set to the destination organization:

The change set is now being uploaded to the Production organization and a notification email will be sent to inform you when the corresponding inbound change set is ready at its destination. This can take a few minutes, so don't panic if you don't see the email instantly.

Jump to the destination organization and navigate to Setup | Environments | Change Sets | Inbound Change Sets. Find the new change set and click on it. You may encounter the following message:

Again, don't panic… it's just that Salesforce still isn't ready to deploy it. Wait for a few more minutes. This is what you will see when the change set is ready to be deployed:

Click on the Validate button to validate the change set before deploying it. The system will provide you with a few choices regarding validation on the Apex test's execution:

• Default: Depending on the current organization, Salesforce automatically runs all local tests (production) or not (sandbox).
• Run local tests: Salesforce automatically runs all local tests (I suggest this for complex change sets, even in sandboxes).
• Run all tests: Salesforce automatically runs local and managed tests (this is related to managed/AppExchange packages).
• Run specified tests: We can select the Apex test classes to be executed (to speed up deployment times; this is something your developers will tell you to do).

Leave the selection as the Default and watch the engine validate your package (from Setup | Deployment Status):

What happened? The new lead field (called Next_Action__c) has not been added to the outbound change set on the source organization, and thus Salesforce cannot deploy field updates nor workflow rules. The change set is not valid.

Let's get back to the source organization, jump to the already uploaded change set, and click on the Clone button. Lastly, add the new custom field on lead (we called it Next_Action):

All the other components are still there; we have simply added a new item to the list.

We should not encounter any errors on the destination sandbox when validating the inbound change set.

Before uploading the change set, we also need to include permissions for the new field (so that we don't have to set up an FLS (short for field-level security) on the new custom field manually).

We can do this in two ways:

• Add a new permission set to the change set components list (if the new features come with a permission set).
• Add the impacted profiles to the Profile Settings For Included Components list.

In both cases, only the permissions related to the components list are considered (for example, if you have a permission set that sets FLS for the case's fields, they are not applied to the destination organization along with the change set because the case's fields are not included in the change set. The same applies to profiles). The following screenshot shows that three profiles have been added to the change set:

Now, let's upload this to production and validate it again. Go back to the destination organization and click on the Validate link next to our new inbound change set version:

We should get a green light upon validating the change set:

Jump back to the inbound change set details page and click on the Deploy button (leaving the Default value as it is for Apex tests). You should get a success message:

The components are now included in your organization, along with the necessary permissions.

Let's go over some more advice regarding this process:

• Add all the dependent components for a given item (for example, all the custom fields for a given custom object or all the workflow actions for a given workflow rule), otherwise the deployment will fail.
• You can deploy along with validation, but validation is useful when you want to know whether the change set is okay ahead of its actual deployment (depending on release management policies, you may only have a given time frame to deploy a change).
• Limit change sets to 10,000 items to avoid long-running uploads and deployments.

Let's move on and discuss using packages to deploy configurations.