Written By:
Matthew Steiner | Salesforce Architect
When it comes to managing Salesforce, are you committing “the ultimate sin” and configuring in production? It’s more common than you think and for a variety of reasons, one of the biggest of which is convenience.
It can really be a hassle to configure a small change in a sandbox and deploy that to production. Add in multiple sandboxes in a pipeline and you’ve now spent more time deploying something than actually configuring it.
Sandbox Lifecycle
Believe it or not, Salesforce sandboxes did not always exist, but it didn’t take long for Salesforce to realize that administrators and developers would need a separate environment for development processes, and thus sandboxes were released.
At first, the “deployment” of changes between environments was completely manual. Then Salesforce released Change Sets to deploy metadata configurations, automations, fields, custom objects, and more from environment to environment.
For most standard configuration changes, Change Sets work just fine. However, there are some limitations that make change sets time-consuming to create. Put enough of these hurdles in place and you can see why Salesforce admins are tempted to just configure directly in production. There are some tips, tricks, and tools that admins have adopted to ease the burden, but at the end of the day, the Salesforce platform’s change sets aren’t everyone’s favorite tool.
In 2009, Salesforce developers introduced DevOps, a set of practices and principles aimed at improving collaboration and communication between software development and IT operations teams to automate and streamline the software development and deployment process. This is NOT to be confused with the tool, Salesforce DevOps Center.
In the project management world, the traditionally used approach was called “Waterfall”. In a nutshell, users would spend a lot of time getting all requirements up front, then build once, test once, and release once.
In theory, this seems efficient, however, technology changes so rapidly, and organizations found that their projects took so long to complete that the requirements would change before the build was finished. So “Agile” project management was born.
Agile can mean a lot of things within a DevOps process, but the key difference between Agile and the Waterfall approach is that you break down the project into smaller phases, iteratively deploying new features to your production environment for use.
Ultimately, the goals of DevOps align with Agile practices and for that reason, Agile has almost become the de facto standard for software development.
Over the years, DevOps and project management tools have matured, while Salesforce deployment tools have mostly stayed the same, until December of 2022 when Salesforce released DevOps Center to optimize the deployment process.
Change Sets vs DevOps Center
Change Sets and DevOps Center perform very similar functions, deploying metadata changes from one org to the next, but the user interface and the behind-the-scenes are drastically different.
The biggest difference is that DevOps Center introduces a third party; a source code repository. Salesforce uses what’s called a “Multitenant Architecture”, where multiple customers share the same server. What’s cool about that is that Salesforce customers can customize their instances to meet their needs. Those configuration changes are stored in XML files called metadata, and these metadata files are stored in the source code repository (aka “repo”).
These repositories have tracking tools that monitor changes and store copies (before and after snapshots) of changes within the monitored Salesforce org. Did someone say backup and recovery? This is wildly beneficial when you have multiple developers working in the same areas as it helps reduce overwriting each other’s work and introduces a version control system. It also introduces the ability to formalize the deployment workflow into business processes to reduce risks.
There are a variety of repository tools out there, and, at present, Salesforce utilizes a cloud-based GitHub-hosted github.com account.
The other key difference between Change Sets and DevOps Center is that DevOps Center formalizes the deployment pipeline. With change sets, you are performing “org to org” deployments. When properly configured, you can deploy between sandboxes and production in any order. While that flexibility may sound great, it becomes extremely manual to ensure your entire Salesforce ecosystem, production, and all sandboxes are in sync. If environments are not in sync you risk losing work, impacting automation, and overriding the ‘invisible work’ like security controls, and much more.
With DevOps Center, you configure a “Project” and then a pipeline to officially declare what actions are taking place in which environments, and additionally control the order and direction of the deployment process.
For example:
• Approved Work Items sandbox is your development environment to create objects and automation. Upon successful testing, you deploy the configurations to the…
• Integration sandbox, which is preconfigured with external data integrations. This sandbox is prescribed to test development configurations with external integrations, and, upon successful testing, deploy the configurations to the…
• UAT sandbox, which is where your end users can access the new features in conjunction with other workstreams and integrated tools for UAT purposes. Upon successful testing, in the UAT sandbox, the work can then be confidently deployed to the production environment.
DevOps Center also introduces a term called Work Item, a feature similar to change sets in that they represent a collection of changes you want to deploy, but what happens behind the scenes is different. When you create a work item, you generate what’s called a “feature branch”.
As the name implies, the “branch” is a copy of the main code base with only your changes applied. When you are ready to deploy, you “create a review” which creates a pull request. An admin, architect, development team, or release manager (whoever you designate) can see all these pull requests from all the developers and review them to make sure the right things are being deployed and nothing breaks or overwrites work.
Repository tools do a great job of highlighting changes in different colors so it’s clear what’s changing and, most excitingly, users actually get to look at the raw XML files that are changing! It’s helpful to see these files to understand how Salesforce works behind the scenes, which, in turn, helps you start to learn code and understand what can be deployed and even makes you a better Salesforce resource.
Change Sets do not have the ability to expose any of these features, regardless of any browser extension or Salesforce application.
That may sound like a lot of intimidating technical jargon, but Salesforce has done a nice job of keeping the interface very simple while allowing you to delve deeper should you need to.
Pros of Using Salesforce’s DevOps Center
You’ve probably picked up on some of the benefits of DevOps Center by reading up to this point, but let’s dive in a little deeper.
Strongly Encourages Source Driven Development
One of DevOps Center’s biggest benefits and a key differentiator from traditional org-to-org deployments with change sets is that it encourages source-driven development. By introducing a centralized source code repo, your configurations are backed up in the cloud, snapshotted (version control), and have excellent change-tracing ability—not just the files but the specific changes within the files, by whom, and when. As organizations continue to grow, it becomes more and more important to recover or rollback any unintended changes. DevOps Center does not force you to use this feature for all deployments, but users are encouraged to via the user interface.
Enhanced Collaboration between Development Teams and Operations Teams
By introducing Work Items, the tool naturally provides a way for team members to follow an agile/store/feature branch/continuous integration/continuous delivery methodology. Currently, the tool is very limited and this could still technically be done in a way with change sets, however, it would require very strict naming conventions.
Able to Deploy More
Admins rejoice! There are some metadata items that Change Sets simply do not support the deployment of. This means they are manual and done by humans, therefore more prone to error. DevOps Center more closely aligns with what is allowed to be deployable via the Metadata Coverage Report. Some areas where DevOps cannot deploy are Salesforce data / data sets or the installation of AppExchange products.
Streamlined Deployment
This one is my personal favorite function! As a Salesforce Architect, I often manage 2-5 sandboxes within a pipeline, and deploying through each of those environments can be extremely time-consuming. With DevOps Center, Work Items are created once and then deployed up the pipeline with just a few clicks, negating the need to re-create the deployment with individual Work Items for each environment.
Furthermore, the process of adding metadata changes to Work Items is much faster, too. Part of DevOps Center setup requires you to set source tracking, which allows the tool to monitor for changes in the background. When you create a Work Item, you can click on the “Pull Changes” button to generate a list of everything that’s changed. Additionally, the search is improved for finding items— out-of-the-box Change Sets can be extremely click-intensive.
FREE/Native Salesforce
DevOps Center is a native Salesforce tool that is free with your standard user licenses. It does require the installation of a package in the production org and some configuration and setup with Github. But it’s 100% supported by Salesforce and is very budget-friendly.
Increases Salesforce Knowledge
Even if you are not a developer and have no plans to be, it is extremely valuable to be able to see the raw XML changes that are happening behind the scenes. Like an introductory coding class, you begin to naturally understand how changes are impacted. It improves your understanding of what needs to be deployed when you make changes which makes your deployments more successful and less risky.
A Few Drawbacks of Salesforce’s DevOps Tool
DevOps Center is not all sunshine and rainbows. As it stands, the tool is pretty basic with a slimmed-down interface offering minimal options and flexibility.
There Is A Learning Curve
Once DevOps Center is set up, it’s pretty straightforward and easy to use, but for someone brand new to this, it may be a little intimidating. It requires setting up a third-party GitHub account and provisioning appropriate access. There’s also the potential for some increased complexity in the deployment process.
Story Integration
To date, there’s no integration with story tools such as Jira, which is disappointing because there’s a huge opportunity for streamlining operations here. That said, a workaround is simply naming Work Items after Jira numbers and placing links to Jira story in descriptions manually for now. Rumor has it that this upgrade is already in the works, so stay tuned!
Edits and Changes
Presently, there is no easy way to make a change to a Work Item midway through the pipeline to production. In doing so, Salesforce immediately releases control and makes you the driver. In most cases, you are really better off changing the Work Item to a status of “Never”, hiding it from the UI, and starting over on that Work Item. This is the cleanest way to keep things flowing smoothly. Additionally, there’s no cloning, so you are re-building packages from scratch.
General User Experience
To my surprise, the general user experience, or UX, is not great.
In order to access DevOps Center you have to log in to production. As developers, we live in sandboxes and generally avoid production orgs to avoid accidentally editing something in the wrong org.
Additionally, the center leverages a special interface that controls your navigation and a number of links can’t be opened in a new tab by right-clicking, which means a lot of back and forth.
Pull changes often did not detect permission set changes, so I had to end up deploying them manually. As a workaround, I made a habit of always grabbing permission sets manually.
When you select metadata items, if you leave the screen to grab more, it unchecks the previously selected items. The best process I’ve found is to just make sure the list has everything you need, sort by metadata item, and then select the items you want to deploy.
The tool offers a nice pipeline view similar to the Opportunity Kanban view, but the click path is inconsistent, often moving between bottom right, top right, or left middle. Most people are accustomed to the standard next-next finish.
Lastly, metadata labels are inconsistent. For example, in the Salesforce Development UI it’s called a Sales Process for Opportunity Stages, but when deploying it’s called a BusinessProcess. Seasoned Salesforce veterans have memorized these nuances, but new users are likely to get confused. The UX leads me to believe this tool is aimed or geared towards more simplified environments.
Alternative Solutions
Competitors like Gearset, Copado, Flossum, and Prodly provide similar tools, with added features and a stronger UI— but with a fairly substantial price tag. Depending on the complexity and size of your organization’s deployments and governance, the annual investment might be justifiable.
Gearset provides a fantastic user experience, with the most flexibility, and the easiest barrier to entry. But it is costly.
Copado is the most robust and sophisticated tool I’ve used and is suited very well for mid-large size organizations.
Flossum and Prodly are very strong competitors as well. Prodly is recommended for organizations that have Salesforce CPQ deployments as it can sequence data configuration changes nicely. Salesforce Ben has a more in-depth guide on these and other alternative tools.
Conclusion
Whether you have a low-code, simplified Salesforce environment, or a complex, apex-filled powerhouse of a system – if you do not currently have a DevOps tool in place and are still using Change Sets, this tool should be a no-brainer.
I’ve personally implemented it in a number of Salesforce orgs for customers that have very minimal Salesforce experience and it works well for their needs and the development process we’ve defined together.
If you are a larger more mature organization, you may still want to try this tool out to see if it’s a fit for you, however, I suspect you may quickly outgrow it as it is today.
If you are looking for a Salesforce Consultant to guide your team through the implementation process and deliver a custom solution for your business, contact The CRM Firm.
Author’s Bio and Contact Information
Matthew Steiner is a 10x Certified Salesforce Professional and Triple Star Salesforce Ranger. He’s been working with Salesforce since 2009 in a variety of environments and roles for organizations large and small. He’s currently a Salesforce Architect for The CRM Firm.
