DevOps has rapidly become the gold standard for Salesforce development. So it’s great to see Salesforce beginning to invest in DevOps by releasing DevOps Center — encouraging even more Trailblazers to start their DevOps journey.
But how does DevOps Center compare to change sets? And what option should teams choose? In this post, we’ll look at these two native deployment tools, the functionality they offer, and considerations when finding the right solution for your team.
What are change sets?
Change sets are a native and free deployment tool provided by Salesforce to move metadata from one org to another — an outbound change set is uploaded from the source org then deployed as an inbound change set to your target org.
It’s important to note that change sets don’t support “arbitrary” org connections — this means change sets can only be deployed between orgs that are related to the same production environment.
Enabling change sets
Change sets are available in Classic and Lightning Experience for Enterprise, Performance, Professional, Unlimited, and Database.com editions.
To enable change sets, log into your target environment. Navigate to Setup > Deployment Settings > press Edit next to the name of the org that will be sending the change set > select Allow inbound change sets > Save.
You can check the connection has been made successfully from the Deployment Settings page, as there should now be a green arrow visible from the source org’s name to the target org’s name.
Key features of change sets
Once you’ve enabled change sets for your chosen source and target orgs, you can begin deploying changes. Here are some of the key features of change sets:
No-code deployments
Salesforce has been designed as an intentionally low-code platform — the same is true of change sets. Building a change set is done with clicks, by simply selecting the components you want to include as part of your deployment package.
Dependency overview
When building your change set, you can click through to view dependencies for the components you’re including in the deployment. You’ll need to add any dependencies manually or the deployment will fail and you’ll need to rebuild the change set.
Some deployment cloning abilities
You can clone outbound change sets from your source and deploy to other target orgs. But to deploy from the first target org (e.g. Integration) to the next environment in your pipeline (e.g. Staging), you need to rebuild the change set from scratch. Ideally, you’d be able to clone the deployment from the target org, to capture any integrated work or additional changes made — but being able to clone deployments from the source can help save time in your release process.
Limitations of change sets
Although teams across the ecosystem are still using change sets, there are some widely acknowledged pain points.
No change tracking or org comparisons
Change sets don’t support change tracking and can’t show the metadata differences between your orgs. This means you’ll need to manually track the changes you’ve made, to make sure you include them in the deployment package. You can also end up overwriting other people’s work or creating out-of-sync environments.
No destructive changes or rollback
Change sets don’t support destructive changes or deployment rollbacks, so metadata has to be manually removed from your live environment if it’s no longer wanted. This leaves room for human error and makes it difficult to predict the impact of the deletion on your wider org.
No support for source control
Changes can only be moved from org to org, with no way to commit changes to a version control system. As Salesforce teams get bigger and orgs get more complex, this makes it incredibly difficult to avoid overwriting each other’s work.
Uncertainty about the future of change sets
While Salesforce hasn’t announced plans to retire change sets, they strongly recommend that customers adopt DevOps best practices and graduate from the org-to-org release model. This is similar messaging to when Salesforce advocated that teams migrate to Permission Sets rather than permissions on Profiles — permissions on Profiles are now going to be retired in 2026.
Ultimately, change sets are a rudimentary — and often painful — way to deploy metadata across your Salesforce orgs that cost time and money in the long run.
What is Salesforce DevOps Center?
DevOps has become the go-to development model across the Salesforce ecosystem over the last ten or so years, with third-party platforms like Gearset providing DevOps solutions that help teams apply DevOps best practices to their development pipeline. Salesforce released DevOps Center more recently, to encourage even more teams to start adopting DevOps.
DevOps Center helps Salesforce teams begin to apply DevOps best practices to their development pipeline by integrating version control into the release process with automated change tracking. This is a big improvement on change sets for metadata management.
Installing DevOps Center
DevOps Center is available for Enterprise, Performance, Professional, Unlimited, and Developer Editions of Salesforce Lightning. While DevOps Center is also available in Government Cloud Plus, be aware that DevOps Center can send data outside of the authorization boundary, leaving your org at risk of compliance breaches.
DevOps Center is a managed package that should be installed in the final org in your release pipeline (i.e. your production or live environment) and cannot be installed in a sandbox. Log into your production org and go to: Setup > Search “DevOps Center” in the Quick Find box > select DevOps Center > Install. If you’re using a Professional edition org, make sure to allow API access before attempting to install DevOps Center or the install will fail.
You’ll then need to create a connected app — which makes DevOps Center accessible from the App Launcher — and assign the relevant permission sets to yourself and anyone who needs to work with DevOps Center.
Key features of DevOps Center
DevOps Center goes beyond change sets in several ways, providing functionality for teams taking the first steps towards Salesforce DevOps.
Version control
Version control is foundational for successful DevOps, allowing development teams to introduce a single source of truth for easy collaboration and identification of conflicting code, which helps avoid overwriting each other’s work. DevOps Center has taken a big leap from change sets by supporting version control.
Version control is mandatory when working with DevOps Center and changes can be made both through the point-and-click interface in DevOps Center or in the version control system itself — so teams made up of developers and admins should still be able to work together using the same workflow. DevOps Center also warns you about code conflicts to avoid overwritten code.
Work items
A new addition in DevOps Center is work items, which act as a ticketing system to capture information about the aims of a project (e.g. building a new feature or fixing a bug), what metadata is involved, who that work is assigned to, and where that work item is in the release pipeline. The metadata changes included in a work item are grouped and deployed together — so, unlike change sets, the deployment doesn’t need to be re-built with each promotion through the release pipeline.
Automation
Automation is essential for mature DevOps, reducing manual effort and lowering the chance for human error. DevOps Center has begun to introduce some elements of automation, with automated change tracking, so no more noting down changes in a spreadsheet! Though keep in mind that DevOps Center doesn’t currently deliver an out-of-the-box CI/CD solution, to help teams automatically move changes through their release pipeline.
Destructive changes
A great improvement on change sets is that DevOps Center supports destructive changes — so you can now thoroughly test deletions in early environments before deploying through to production, without the risks associated with manually deleting configuration in your live environment. As with change sets, there’s still no support for deployment rollbacks.
Enhance with extensions
While DevOps Center doesn’t provide full DevOps functionality, it can integrate with additional extensions to get closer to a mature DevOps process. For example, Provar released their DevOps Center Plugin on the AppExchange — this plugin is available to those with a Provar Manager subscription and enables quality testing throughout the release pipeline.
Limitations of DevOps Center
While DevOps Center has begun to fill the gap in native offerings from Salesforce, there are some limitations to keep in mind if you’re looking to implement DevOps for your Salesforce team.
Limited version control integrations
At the moment, DevOps Center only integrates with cloud-based instances of GitHub and doesn’t offer support for locally hosted versions or GitHub Enterprise Server. Salesforce does have plans to add support for additional version control systems and BitBucket Cloud is currently in beta. But there isn’t an ETA for when more version control integrations can be expected.
No back promotion
Orgs within your release pipeline can diverge easily. For example, if developers are working in their own individual orgs and deploying to a shared environment, their orgs will quickly become out-of-sync. Being able to back-promote those changes through to earlier environments keeps orgs in sync throughout the release pipeline. Unfortunately, that isn’t supported in DevOps Center.
No “arbitrary” org connections
As with change sets, DevOps Center doesn’t support deployment between orgs that don’t share the same production environment. If you manage multiple production orgs, or are a consultant working with a variety of clients, you’ll have to replicate development across each pipeline.
Updates aren’t always automatic
Although Salesforce aims to automatically update orgs when a new version of the DevOps Center package is released, this doesn’t always happen. You can manually update the package through the DevOps Center Setup page.
No support for package-based development
If your team has adopted package-based development as part of working with Salesforce DX, you won’t be able to use DevOps Center. This approach isn’t supported, so you’d need to revert to org-based development.
Mature third-party Salesforce DevOps platforms
Although DevOps Center is a recent arrival on the scene, DevOps isn’t new to the Salesforce ecosystem.
Over the past 10 years, Gearset has built a full DevOps platform that can meet you where you are and scale with you as your processes mature.
- Compare and deploy across all environments. Compare the metadata between your orgs, scratch orgs or version control branches to see exactly what’s different. Build deployments in a matter of clicks with automatic fixes for common issues and integrated ticketing. Once deployed, easily redeploy from the target to another environment or roll back if something needs reverting.
- Full automation suite. Lower human error and get your deployments running rapidly with end-to-end CI/CD. Keep an eye on your code coverage with automated unit testing. And quickly spot unexpected changes with daily change monitoring.
- Robust data management. DevOps involves more than just deploying metadata — establish realistic testing environments with sandbox seeding, protect business critical data with backup, and streamline your org’s data with archiving.
Choosing the right option for your team
Here are the key considerations to keep in mind as you decide on the right platform to support your Salesforce team.
What pains are you trying to solve?
Finding the right solution for your team should always depend on what problem you’re trying to solve. For example, if you’re struggling to get your deployments to run successfully with change sets, moving to DevOps Center is unlikely to be a good next step. Adding the complexity of version control to deployments that are failing will make the release process more complex. In instances like this, it’d be better to find a solution that can meet you where you are and get your deployments running smoothly, before beginning to layer in DevOps best practices.
What is your ideal development process long-term?
When weighing up the best option for your team, keep in mind your end goal — DevOps Center can be a good first step on the ladder to get familiar with version control. But, if you want to implement CI/CD and other processes involved in mature DevOps later, you won’t be able to achieve that with DevOps Center. At some point, you’ll need to graduate from DevOps Center to another solution. The time needed to get up to speed with one solution only to move to another shortly after can be a huge time and resource sink.
What ROI are you expecting?
A big draw to native solutions is that they’re free — for teams with limited budgets, this can seem like the best option. But DevOps bolsters your bottom line, and that return on investment only increases the more mature your DevOps process is.
The State of Salesforce DevOps 2024 report found that 97% of all teams saw a monthly return on investment from Salesforce DevOps but not all teams are getting the same amount of return. For elite teams, 25% saw a staggering $100,000 per month return from Salesforce DevOps. Meanwhile, only 14% of non-elite DevOps teams saw that same return. When implemented properly, DevOps pays for itself and more — so it’s worth investing in a solution that can help you achieve a complete DevOps process.
Future-proof your DevOps success
It’s great that Salesforce introduced DevOps Center to address some of the limitations of change sets, encouraging even more Salesforce teams to implement DevOps. And while mature DevOps isn’t yet possible with DevOps Center, there are some key improvements on their roadmap.
Even so, only Gearset can solve the deployment pains of change sets straight away, then help you build a mature DevOps process far beyond what’s possible with DevOps Center.
Speak to one of our DevOps experts for tailored next steps and guidance, or try all of Gearset for 30 days free of charge.
