[Analysis] 7 Options For Deploying Salesforce Changes. What’s best for your org?

I am always asked, “What are my options for deploying Salesforce changes?”

To help answer this question, I wanted to summarize the wide variety of tools available for deploying Salesforce changes between orgs and some information about their key strengths or suitability. The vital thing to remember is that there isn’t a single tool to fit everyone’s unique requirements. Many teams use a combination of these tools depending on the risk of the change and the urgency to get a fix into production for deploying Salesforce changes.

Source-driven vs. org-driven

When choosing release management tools, it’s essential to consider if you want to follow a source-driven or an org-driven development approach when deploying Salesforce changes.

Source-driven development is the standard method outside of the Salesforce ecosystem. It has always been possible with Salesforce but never easy. Before Salesforce DX, source-driven development was complicated, brittle, required dedicated team members, and was prone to human error when merging XML changes manually. With Salesforce DX, we can use scratch orgs (or sandboxes) to develop atomic changes and then sync them into our source code repository. When we want to deploy changes to another environment, we don’t move the current copy of that item to the original org. Instead, we move the copy of the metadata that we committed to our repo. We can even use the Salesforce DX package to manage every release version and roll back to an earlier version with just a few clicks.

Org-driven development is akin to Microsoft or Apple making changes by implementing the changes on your colleague’s machine and then copying the files they updated to yours. Who knows what other unintended change will be picked up? In my mind, it’s one of the significant causes of the ‘It works on my org’ comment that some developers are often (rightly) accused of making too often. Many Salesforce consultants find source-driven development too complex to set up and manage (until DevOps Center). Their only choice is to use source-driven development and follow strict processes for managing changes and avoiding issues.

For me, using a source-driven approach is the only way to have a reliable and repeatable deployment artifact that you have a copy of and can roll back to at any stage. An org-driven approach is straightforward when starting, but once tools like DevOps Center are available, I struggle to see reasons to continue.

I’ve listed the tools below chronologically for when they became available in the Salesforce ecosystem. At Provar, we’ve made it our mission to work with all these tools, including the DevOps Center, which isn’t even available yet.

7 Options for Deploying Salesforce Changes

(1) Salesforce Setup (Free)

The power of Salesforce has always been the speed of change. This blessing has also been a curse for creating production issues.

Suitable for:

Sandboxes and scratch org-driven development
Changes as a last resort

Key features and challenges

Some organizations that don’t use sandboxes make changes directly in production. We highly recommend only doing this in a sandbox or scratch org and using the other options below to manage deployments.
There are some edge cases where admins need to make immediate changes as changes can’t be deployed through the metadata APIs, but these are thankfully becoming rare.

Provar support

Provar Desktop can test the org and rerun tests for different profile types. Test data is tracked and can be rolled back after completion. When you move to sandboxes, the test cases are fully reusable with no changes or remapping.

(2) ANT Migration Tool (Free)

Command line deployment using ANT and metadata API.

Suitable for:

Org or source-based development
Teams with ANT & CI/CD expertise

Key features and challenges

The original deployment tool when deploying Salesforce changes
Requires a specialized skill to resolve issues, optimize and understand profile impact on deployments, and create rollback scripts. Can deploy changes across orgs.
It can be integrated into generic CI/CD pipeline tools such as Jenkins, CircleCI, Azure DevOps, etc.. that support ANT tasks.
Generally only effective with rich source tracking for declarative and code changes. Involves coarse-grained metadata, meaning that changes can include unintentional changes.

Provar support

Provar’s ANT CLI can be used to test cases authored in Provar Desktop to generate a formatted report of results with screenshots
Unlike most web test tools, Provar tests are bound to the metadata elements (not the DOM) and are not impacted by changes after deployment to another sandbox or org

(3) First Generation Packaging (Free)

Unmanaged and managed packages are typically created in a Developer Edition org and can be shared on the AppExchange.

Suitable for:

Org or source-based development
AppExchange publishing

Key features and challenges

Unmanaged packages allow developers to bundle changes for deployment into any org and then allow those changes to be edited in situ, i.e., unmanaged.
There is no ability to upgrade or version unmanaged packages
Managed packages primarily for ISVs but used by companies with multi-orgs to roll out versioned changes to core elements
Multiple profile images can be applied to an org on installation. Limits on changes for items in a managed package and no option to downgrade the version.

Provar support

Provar’s namespace overrides allow developed packages to create tests on the DE orgs and re-run them on their packaged deployment to validate changes.
Test projects can be shared with end customers to help them extend tests as part of their deployment and release management processes.

(4) Change Sets (Free)

Build change sets to push from one org for deployment to another.

Suitable for:

Org-based development
Salesforce admins

Key features and challenges

Easy to use for all admin users. Change sets revolutionized deployments c. 2013 and allowed admins to move changes fast between environments without creating an unmanaged package first.
Unlike packages and the ANT migration toolkit, change sets are limited to orgs related to a single parent org. You cannot use change sets to move code or config between unrelated orgs.
Change sets can be cloned to create different versions. Once deployed, these changes are locked to a snapshot of the changes at that time. This is good from a release artifact perspective but painful when your change set gets bigger and bigger.
This gave rise to the infamous Salesforce deployment fish (Google it or check out #deploymentfish on Twitter), where more components are deployed (e.g., 26/20) than you thought. It turned your nice green circle into a weird green fish.
No automatic change tracking: some changes were missed in deployment, other changes were included by accident, or changes were included that were not required, which risk compromising other changes

Provar support

Provar Desktop and Provar CLI can be utilized to validate changes before pushing change sets to document the test behavior in the source org
Provar Desktop and Provar CLI can be utilized to rerun the same suite of tests after deployment to confirm all post-deployment steps have been completed and produce a smoke test report to stakeholders
Post-deployment steps, such as activating Salesforce Flows and recompiling Apex, can be triggered from within Provar as test steps

(5) Third-Party Release Management Tools (Paid)

This includes in-org tools like Flosum, hybrid solutions like Copado and AutoRABIT, cloud applications like Gearset and Blue Canvas, and desktop tools like Metazoa and AppirioDX.

Suitable for:

Org or source-based development
Teams with weak source code management experience
History of changes deployed to each environment
Org monitoring for changes made to critical environments

Key features and challenges

Each of these tools is commercial and has features and benefits. These include change tracking, org compare, multi-org support, conflict management, source code management, and deployment schedules.
Some notable features of the best tools include rolling back changes to an org after deployment and monitoring production orgs for in-org changes.
It’s worth noting that all these tools currently only manage changes in Salesforce and don’t support managing releases to any other platform.

Provar support

Products can run the Provar CLI locally or make webhook callouts to trigger test execution using a cloud-based or private server CI/CD.
Provar tests verify end-to-end behavior, validating different integrated business systems compatible with the changes deployed.

(6) Salesforce DX (Free with limits)

Salesforce DX is a vast program of multiple changes to fix issues with packaging, break down coarse-grained metadata, provide natural source control integration, and ultimately make source-driven development the new normal.

Suitable for:

Primarily source-based development
Teams with weak source code management experience

Key features and challenges

Salesforce DX includes features such as a new fine-grain metadata format for better source code management and deployment, automatic change tracking, second-generation packaging, a Dev Hub for managing all your orgs, VS Code integration, and scratch orgs for creating environments on the fly.
Salesforce DX is easy to learn but generally perceived as a developer-only tool. It is difficult to break down the legendary ‘Happy Soup’, though recent changes such as org-dependent packages will help.
DX commands can be integrated directly into generic CI/CD pipeline tools such as Jenkins, GitLab, Azure DevOps, CircleCI, etc.
To date, the primary users who have switched to Salesforce DX tend to be those who used the ANT migration tool and are metadata experts and want to leverage the benefits of second-generation packaging, which primarily includes ISV partners. This is starting to change.

Note: Many third-party tools also support Salesforce DX metadata and can use the Salesforce CLI commands.

Provar support

ProvarDX^TM is available as CLI and VS Code extensions to make testing seamless with Salesforce DX.
ProvarDXTM’s Dev Hub integration allows environments to be overridden dynamically at runtime and unlocks the use of scratch orgs for testing early and testing often.

(7) DevOps Center (Developer preview)

Think Salesforce DX for admins, a.k.a. Salesforce Admin experience.

Key features and challenges

DevOps Center leverages all Salesforce DX technology, such as source tracking, to identify changes, making integration with version control platforms and CI/CD pipelines easy.
Appears to be competition for the third-party release management tools but does not have the same feature parity yet. At the very least, it’s a welcome successor to change sets.

Provar support

Using Provar CLI And ProvarDX^TM, test cases can be executed when a change is ready for review and linked to the Work Item in the DevOps Center.
After changes are deployed to an environment in the pipeline, Provar tests can be executed to carry out smoke testing of the specific change or to complete a full regression test, depending on the stage of your pipeline.

Summary

The following matrix provides a quick recap/comparison for the above section. (Note: You can click to enlarge the image.)

Useful information

Trailhead: Application Lifecycle Models

VTDX20: Release Management Patterns (Select track seven.)

Learn more about Salesforce and the Spri’21’21 release

Learn more about new features coming soon to a Salesforce org near YOU! Join us for our WhaWhat’sw in Spring ’21’21ent, where our very own Salesforce SME Sarah McCarter will be on hand to answer your questions and break down exactly what you need to know. RSVP today!