The new Spring ’23 Release from Salesforce is almost here. And it brings with it a big change that will help Admins and Developers alike manage their environment setup. Let’s jump in ‘deep dive’ into at the DevOps Centre, released as part of Salesforce Spring ’23 Release.
DevOps Centre – Now ‘Generally Available’
Yes, Salesforce DevOps Centre hits the ‘GA’ (Generally Available) milestone in the Spring ’23 Release.
This is potentially big news for a lot of organisations! Let’s take a step back and see why there is a lot of noise around this in the Salesforce community.
Quick note: I am going to try and walk the fine line between dev and admin here in this post... I am aware some of these concepts will be very new to some people. If this is you, please check out the Other Resources section at the bottom of the page. Where I have tried to include a few links to help provide additional background/context.
Brief history of Change Sets
If you have any experience managing Salesforce as an admin or dev, you would likely have used Change Sets. They are ubiquitous with Salesforce. And have helped users move changes from one environment to another, without having to ‘redo’ the work manually.
For a long time now, a Salesforce user with appropriate permissions could prepare a number of changes in an environment, like a sandbox (eg page layout changes, new fields, custom metadata/settings, etc). And then use Change Sets to group these changes together and move them between various connected environments.
It has been a very useful tool, but not without its limitations. Especially as the Salesforce platform rapidly expanded beyond ‘simple’ changes and products over the years!
As development requirements progressed and orgs became more sophisticated, organisations looked for specific tools to manage their Continuous Integration and Continuous Delivery efforts (commonly referred to as CI/CD).
Many organisations have also required the ability to not just deploy changes. But also track version history and changes made to elements within Salesforce.
As teams developing/configuring Salesforce environments scale in size, Change Sets simply haven’t been able to ‘keep up’. Especially with some of the alternative methods to manage deployments now available to organisations. Dev tools now manage Salesforce components via Metadata API and integrate with platforms specifically made for this situation (eg Github Actions/Bitbucket Pipelines).
Why ‘DevOps Centre’?
This leads us to the problem Salesforce is trying to fix. Why is Salesforce is releasing the new DevOps Centre?
Simply put, Change Sets are not ideal when dealing with complex releases. Having to rely on someone to manually track the changes (like field updates, page layouts, profiles, setup options, etc) and then add all of these changes into a Change Set, is an extremely cumbersome process.
This is why tools like the above mentioned CI/CD pipelines, actually exist in the first place.
By integrating with a source control system (eg Github/Bitbucket/etc), DevOps Centre gives Admins/Devs immediate access to track changes made within an environment.
Additionally, most orgs these days, have Admins and Devs alongside additional project support staff (like Business Analysts/Release Managers/etc). Using these tools and having a release governance framework, allows everyone to track the same changes included in release.
Yes, there is a bit of a learning curve.
Althought Dev teams are typically who would use a Source Control system, there is huge value in Admins learning how to use these tools too.
Imagine being able to easily understand how/why a formula field was changed! Or avoiding two people updating the same page layout and losing the changes.
Alternatively, if you have deployed a change set and need to ‘roll back’ a change because something has gone wrong. Having this version control/history available helps to restore your environment quicker.
DevOps Centre – Setup
Setting up DevOps Centre will take a little bit of time and planning. Especially if you are new to things like source control systems (primarily GitHub).
There is a great guide on Salesforce Knowledge Centre, which covers enabling and installation through to managing your environments and how to troubleshoot issues.
Overview of Features
Track Changes & Work Items
In this example, you can see the in progress changes to a number of elements from the sandbox (Karen CB1 Dev1). These changes include two profile updates, along with a new custom object and page layout.
You then you can also view the Activity History, much like Activity History on an account/contact record, this section allows you to view the change history of the work item and even search for specific changes:
To then help coordinate the environment management, DevOps Centre also allows pipelines to be setup. Imagine a pipeline, as simply a defined way to release things from one sandbox to another. Based of your change management governance, all changes can be routed through a pipeline to then be deployed into the appropriate sandbox/environment.
Pipeline / Environment Management
From the Pipeline screen, you can define and connect various sandboxes to the different stages of release management.
Imagine each admin/developer works in a different sandbox to make their changes. Each person might do a Work Item for their changes in their sandbox.
Then merge all the pending changes together into a single Integration/UAT environment, DevOps Centre integrates with GitHub to group all the changes to be released together. And then manages the deployment into the environment.
Take a moment to imagine doing that via only Change Sets…
Don’t other tools already do this?
In my opinion, I will say DevOps Centre isn’t really unique in doing all of this.
As mentioned above other tools have existed in the past, which do a very similar job. Though they have typically been focussed on developers, and less on the ‘point and click’ crowd.
The benefit that I see with Salesforce DevOps Centre, is if your team uses GitHub (or similar) already for development you can now include your Admin team. This should reduce the learning curve that comes with GitHub for people new to version control. While allowing developers/users who already use Salesforce DX, for example, to continue to work with their repository/project.
If you have everyone that configures/develops Salesforce all working in a similar way… When to comes to releasing new customisations/development, the process should be smoother for everyone involved.
There is nothing more frustrating than updating a page layout or profile, only to have someone else overwrite your change and then you have to try and find out why/when it happened. Especially when you have to trawl through different versions of the same Change Set. 🙁
DevOps Centre – Who can use it?
This change applies to Lightning Experience in Developer, Professional, Enterprise, Performance, and Unlimited editions.
As per Salesforce Release Notes: Salesforce DevOps Center hasn’t been tested and isn’t recommended for Government Cloud/Government Cloud Plus.
If you want a broader background on CI/CD, this SalesforceBen article covers a lot of the background and planning side involved with CI/CD and Salesforce.
To get you started there is a great guide on Salesforce Knowledge Centre. This covers installation and initial configuration/linking to GitHub repository.
There are a number of use cases available to read through, on the Learn Moar page for DevOps Centre – which was released when the beta trail started. This looks at use cases including developers and admins. And also how DevOps Centre can integrate into your existing way of working, if you work with third party dev tools.
Additionally, Trailhead now also includes modules relating to DevOps Centre.