Best practices for risk-free Salesforce deployment

 

Different Deployment Methods in Salesforce

Salesforce Deployment is nothing but copying/transferring Salesforce metadata from one Salesforce organization to another. There are various methods to achieve Salesforce metadata deployment.

Different Deployment Methods

1. Change Sets
2. Eclipse with Force.com IDE ( Deprecated)
3. Force.com Migration Tool – ANT/Java based
4. Salesforce Package
5. VSCode Salesforce Extension Pack
6. Salesforce Code Builder

Change Sets

The easiest way to send configuration changes from one Salesforce organization to another is to use a change set though it has a limitation that we can use it among connected Salesforce orgs only (like Developer Sandbox to Test Sandbox & Test Sandbox to Production Org etc). We cannot use it in between any individual Salesforce orgs.

To use change sets we need to have two Salesforce org’s i.e. one Production org and its Sandbox org.

Production Org:
It is Salesforce org with live data which is being actively used.

Sandbox:
A sandbox is a copy of your production organization. Sandboxes contain the same metadata as production organization.

Outbound Change Sets:
Make changes in the organization you are logged into, and upload those changes to another organization.

Inbound Change Sets:

1. Accept, modify, or reject change sets uploaded from other organizations.
2. Change sets require a deployment connection between the two Salesforce organizations.
3. The first step is to create this connection. To create a connection, follow the below steps:

Steps to create Deployment Connections

1. Create one or more sandboxes.
2. Go to Setup >> App Setup >> Deploy >> Deployment Connections / Deployment Settings. It will show you information on Change set and Outbound/Inbound change set information. Press ‘Continue’ button on this page.
3. Click ‘Name’ to view existing connection details. We can see this record only if Sandbox is created for Production Org.

4. Click ‘Edit’ to authorize inbound changes from a listed organization.

Steps to create Outbound Change Sets

1. 1. In a related sandbox org, use Deployment Connections to authorize inbound changes from this production org (same as shown in above screenshot).

1. Go to Setup >> App Setup >> Deploy >> Outbound Change Sets.
2. Click on ‘New’ to create a new Change Set.

4. Click ‘Add’ to include Salesforce components in your changeset.

This displays a list of all Salesforce components like Apex Classes, Packages, Tabs etc. You can choose the type of component and the components you want to add, and then click Add to Change Set.

5. Click ‘Add Profiles’ to add profile settings to the change set.
6. Click ‘View/Add Dependencies’ to add dependent components.
   Dependent components rely on the existence of other components. Unless you are certain that the dependent components exist in every organization this change set will be deployed to, it’s a good idea to add dependent components to the change set.
   
7. Click ‘Upload’ to send these components to another org. Select the organization you want to send the change set to and then click ‘Upload’. 

Steps to create Inbound Change Sets

1. Log into an org that has received a changeset i.e. Sandbox Org.
2. Go to Setup >> App Setup >> Deploy >> Inbound Change Sets.
3. Click a change set name to see its detail.
4. Click ‘Validate’ to validate a changeset without deploying changes. Validating a changeset allows you to view the success or failure messages you would receive with an actual deploy.It is highly recommended to validate Change sets before deploying it.
   This is a good idea if you are planning a deployment in future and want to determine if the deployment will succeed ahead of time.
5. Click ‘Deploy’ to apply the change set to your Org.
6. Once the deployment completes, click ‘View Results’ to see the status and individual changes or errors.

Deployment Status

You can monitor deployments that are in progress, check which deployments are waiting for execution, and view the results of completed deployments on the Deployment Status page. To track the status of deployments, click Setup >> App Setup >> Deploy >> Deployment Status. Deployments are listed in different sections depending on their status.

This is how we can deploy metadata using Change Sets. In our next blog, we will discuss another method of deployment i.e. deployment using Eclipse with Force.com IDE. 

Salesforce makes app development accessible for users of different tech proficiency levels, providing both advanced and point-and-click tools. Salesforce deployment usually takes a fraction of the overall implementation time but if done recklessly, it can entail unpleasant consequences. 

----------------------------

Any change deployed within a Salesforce organization can challenge the integrity of the entire infrastructure. It’s no wonder Salesforce consultants name Salesforce deployment one of the trickiest and riskiest parts as it can affect:

·       Business continuity: Even a small part missing, like an object or a validation rule, can break other parts of a Salesforce organization thus disrupting workflows, preventing users from doing their job, and compromising security. 

·       Compatibility: The existing features and integrations can be incompatible with the new changes and cause serious malfunctions, as well as interfering with data synchronization and automatic uploading. 

·       User adoption: New developments are there to make users’ lives better, but in many cases users experience difficulties with Salesforce adoption. For instance, they can require additional training when dealing with newly-developed functionality. 

Salesforce deployment options

As a rule, Salesforce implementation starts in a developer sandbox. Then changes are pushed to the testing and staging environment, and once testing is done, the changes get deployed in the production environment.

There are three deployment options in Salesforce:

·       Change sets

·      Metadata API

·       Ant Migration Tool

Let’s overview their characteristics and use cases.

Change sets

A change set is a group of features,components, and customizations that can be moved from one Salesforce environment to another—from one sandbox to another or from a sandbox to production—and deployed. 

It works like that. Two organizations are configured to send and receive changes between each other. The user chooses which objects in the source organization to deploy, thus building a change set right in the Salesforce UI. When a change set is created, it can be deployed in the target organization, where it’s possible to accept the changes. As a result, the two organizations will have the same metadata described in the change set.

By its nature, change sets are a friendly option for non-tech users and smaller companies who need to implement quick changes without developer assistance. At the same time, if there are a few environments and many people working on Salesforce development, change sets make it hard to cooperate. They don’t support release management control and version control, which might entail errors and chaotic change tracking. What’s more, change sets don’t support a number of object types like sales processes, email addresses, divisions, and more. So in order to complete a deployment, it’s necessary to move such components manually, which is an extremely cumbersome and error-prone process.

Metadata API

Metadata API is a set of objects that help manage customization information, or metadata, like custom objects or page layouts, in order to:

·       Export customizations from your Salesforce organization as XML metadata files

·      Migrate configuration changes between organizations

·       Modify existing customizations in your organization

·      Move metadata from a local file system to a Salesforce organization

·       Create your own tools for managing organizations and app metadata

Metadata API is a great instrument for managing customizations and building tools that can manage a metadata model, not the data itself. Salesforce also provides Ant Migration Tool to simplify access to the Metadata API functionality.

Ant Migration Tool

Ant Migration Tool is a Java/Ant-based command-line tool used for process automation. It can help perform repetitive deployments that use the same components and can be scripted. 

The Ant Migration Tool is designed for developers; less tech-savvy users would have to face a steep learning curve before grasping it. It requires considerable time and efforts but at the same time it provides greater control over deployment and supports CI/CD. 

The tool comes in particularly handy in the following use cases:

·       Populating a test environment with a great amount of setup changes

·       Repetitive deployment with the same parameters

·       Iterative building, testing and staging prior to going to production

·       Scheduling batch deployments

Note that the tool can be used only in a specific development environment, so it’s not suitable for distributed teams.

Salesforce deployment dos and don’ts

To free deployment from its status of the riskiest Salesforce implementation stage, consider the following deployment best practices.

Do plan everything in advance

Say no to random releases and changes that can disrupt business continuity and confuse users. Instead, plan all the changes and their possible implications prior to going live. 

The plan is particularly important when you work with multiple sandboxes at the same time. In such a situation, the plan lets everyone know what is going to happen and when, while keeping accountable the actors who initiate and implement changes.

It’s much easier to control your deployment and leave room for maneuver when you:

·       Know in advance who’s going to be on the deployment team and what tools you’re going to use: change sets, command-line tools, manual configurations, etc. 

·       Plan a go-live for the least busy time with the majority of users off the system, like a weekend or a Friday night, to avoid work disruption. 

·       Take into account how much time you will need for testing and manual configurations necessary when working with change sets.

It’s also important to make sure in advance that you have the right data and calculate data loading time, as it can take a few days in case of legacy data migration. You also need to think how to communicate changes to end users to let them know when changes are coming, how to account for them when planning their day, and where to seek help in case of any difficulties.

One more essential point to consider when creating a deployment strategy is a roll-back plan. Sometimes things don’t work as expected and jeopardize continuity, so with the help of version control tools, it’s possible to get back where you’ve started, analyze, and fix errors.

To sum it up, it’s recommended to answer the following key questions when building your deployment strategy:

·       Who will be deploying?

·       What deployment tools are you going to use?

·       When are deployments scheduled?

·       Do you need to upload any data?

·       How are you going to communicate the update?

·       What’s the roll-back plan?

Don’t develop in production

Some people develop right in the production environment, which means they don’t need to deploy. It saves time and money but this approach can work only for those companies that run minor customizations that don’t require IT help and additional development and staging environments. 

However, in most cases, development in production entails certain limitations (it’s not possible to write Apex code in production) and destructive consequences and unexpected cascading effects (a modified workflow rule can create an infinite processing loop, or an edited field type can change data in a way that’s impossible to undo). For this reason, it’s highly recommended to develop any change, even a minor one, in a sandbox or a scratch organization, test it, and then proceed to deployment. 

Consider the following tips to develop safely:

·       Limit customization access to minimize the number of people allowed to deploy changes

·       Restrict modification types for change sets

·       Appoint an environment management team to review changes prior to deployment

·       Provide every developer with their own sandbox

Sandboxes are a great tool for auditing and keeping track of developers’ work. There are a few types of sandboxes in Salesforce:

Developer sandbox

An isolated organization that copies metadata into a different environment for coding and testing. Multiple developer sandboxes get linked to a source control system.

Partial copy sandbox

The tool copies metadata and a portion of production data for integration testing and quality assurance and minimizes code overwriting risks.

Full sandbox

The tool copies the entire production organization and data for coding and testing changes in relation to the entire live organization, thus minimizing possible errors.

Don’t skip testing

Testing is a key procedure for securing successful Salesforce deployment and positive user experience. It’s recommended to run tests both during the production and after the deployment.

You can make use of the Apex testing framework to write and execute unit tests to ensure high quality of Apex code and reach all the requirements to deploy it, checking that:

·       Apex classes and triggers work as expected

·       Code coverage is at least 75%

·       Apps going to production are of high quality

At the Partial copy sandbox stage, run integration tests to ensure that updates don’t affect the functionality. When in a full sandbox, run user acceptance tests to make sure the changes meet user requirements, and performance tests to check response time and unintended effects on any of the organization’s aspects. 

Salesforce also allows creating regression tests that can be triggered every time there are updates and ensure that these changes don’t break the existing functionality. 

Additionally, consider implementing test automation to cut on manual testing and speed up releases. Automated scripts can run tests and immediately inform the developers whether their code is safe for deployment.

Do implement code version tracking

Code version control allows tracking and documenting all changes at every development cycle stage, which provides:

·       A single source of truth for all team members, so that they can access a detailed change history

·       Parallel development streams with the possibility to deploy different code versions across development stages

·       Notifications about code conflicts

·       Continuous integration and delivery

Salesforce sandbox development offers limited version tracking, so many Salesforce development teams go for a Git-based version control system which has become a number-one system for version control.

Do create a release management strategy

When developers work simultaneously in multiple environments (development, staging, or production), they need to plan and control their deployments. To establish good governance and run smooth deployments, developer teams need to have a proper release management strategy. Consider the following tips:

·       Create a complete release management process where each team member understands their role.

·       Categorize releases into bug fixes, minor changes with no need for user training, and major changes with significant impact on functionality, dependencies, and adoption.

·       Develop and test in separate environments, and migrate all the changes from every project to the same environment for integration.

·       Make developers aware of other releases and their schedules, and provide them with version control tools.

·       Identify areas of code conflict early in the planning and provide developers with communication tools.

·       Avoid deployment during busy hours or major events.

·       Release on a regular schedule so that users could plan their week by knowing, for example, that major updates usually come on Friday nights and minor ones on Tuesday mornings.

Do follow CI/CD practices

СI/CD practices speed up releases and provide space for flexibility and improvisation. Continuous integration and merging lets developers minimize bugs and dependency issues, and if there are still any, they will usually be smaller and can be easily fixed. As a result, you can deliver new features once they are developed and tested, without waiting for releasing them in one batch.

In Salesforce Developer Experience (DX), it’s possible to pursue the continuous integration approach by making use of scratch organizations—source-driven and disposable deployments of Salesforce code and metadata. When developers regularly integrate code changes into a source code repository, it’s necessary to ensure that the new code doesn’t contain bugs. Scratch organizations allow developers to use integrated third-party CI tools, like CircleCI, Jenkins, Travis CI, etc. for running automated tests for new changes, checking code coverage, and pushing deployment to a target environment.