Reading Time: 6 minutes
What is Salesforce DevOps Center?
DevOps Center, a recent addition to Salesforce applications, is designed to eventually replace change sets in its functionalities. Its improved experience around change and release management brings DevOps best practices to your development team, regardless of where they fall on the low-code to pro-code spectrum.
DevOps Center’s “clicks, not code” UI offers a user-friendly way to streamline release management while also integrating Salesforce extensions for VS Code and Salesforce DX. The end result is Enhanced collaboration between declarative and programmatic developers.
Developers, whether using Salesforce’s point-and-click tools or coding in Apex, can collaborate to provide scalable and repeatable value to the business.
DevOps Center offers flexibility in managing releases, allowing you to choose between its app, the source control system, or a hybrid approach. The game-changer for Salesforce teams is that the DevOps Center manages the source control branch so you can focus on development tasks.
Having all changes recorded in a source control system ensures a unified source of truth for both code and metadata. And with DevOps, you can use this single source of truth for data and configuration data, as well. This fosters collaboration across various functions, including release managers, administrators, developers, QA, and other business stakeholders.
DevOps Center is a completely different product from change sets, and it won’t interfere with the use of change sets. However, it’s important to note that eventually, Salesforce is likely to retire change sets altogether in favor of the DevOps Center.
Benefits of Using DevOps Centre:
DevOps Center significantly improves the change and release management process when developing with Salesforce. It enables you to take advantage of modern DevOps best practices via a centralized, user-friendly interface. The following are some of the key features of the DevOps Center:
- Organize your work: Work Items, a new object designed for the DevOps Center and open to standard Salesforce Flows and other operations, can be used to track and deploy the associated changes.
- Track changes automatically: Changes in development environments are automatically tracked as they are made. In the DevOps Center, you can view a list of changed metadata components and select the ones you want to migrate.
- Integrate seamlessly with GitHub for source control: All you need to do is connect your GitHub account and the DevOps Center handles the rest.
- Deploy changes with clicks: You can create a visual representation of your deployment pipeline, then click to deploy changes from one stage to the next.
Deployment Process:
Creating a new Work Item
The Work Item has three fields in the current version and can be used as a User Story.
Work Item Stages:
Work Item Stages in DevOps Center Salesforce are the different phases that a work item goes through as it is developed, tested, and deployed to production. The default stages are
-
New
The initial status of a work item upon creation. The New status doesn’t necessarily imply that no related work has taken place. Your team could be planning, sizing, scheduling, designing, and so on, in support of this work item. When it’s time to initiate customization development, choose a development environment. The work item moves to In Progress and enables you to launch the environment directly from the work item.
-
In Progress
Work that the listed assignee is actively pursuing in the development environment. In this status, another team member cannot assign this item to themselves or commence working on it. DevOps Center creates a branch directory for it in the project repository.
-
In Review
Work that’s ready for your team members’ review. When you click ‘Create Review,’ the work item transitions to the ‘In Review’ status, and an automatic change request is generated.
-
Ready to Promote
The work item has undergone review and approval, ready for promotion. GitHub confirmed no merge conflicts and compliance with all mergeability rules.
-
Promoted
This work item advances to a pipeline stage, and upon reaching the final stage, it transitions to the Closed status.
-
Closed
Work that is finished, reviewed, thoroughly tested, verified, and progressed through the entire pipeline.
Example:
At the New stage, you must define the location where you intend to work:
- From the Salesforce platform then you’ll select the Development Environment that you connected earlier, OR
- From external IDEs where you will develop and then push changes in the feature branch.
Please be aware that the Feature branch is generated automatically with an identical name to that of the Work Item.
New Custom Field on Account
To incorporate metadata changes into the Work Item, you have two alternatives:
- Pull Changes button – it will pull all the modified changes from the development environment
- Add Components Manually – you can select components manually to add to the Work Item
Create Review:
After committing the metadata component, the ‘Create Review‘ button becomes active in the top right corner. Clicking it transitions the Work Item to the ‘In Review‘ stage, simultaneously creating a pull request in the backend.
Pipeline Promotion:
After initiating a pull request, you can designate it as ‘Ready to Promote,’ enabling the Work Item for promotion to the next stage in the pipeline.
Promote the Work Item to Higher Org:
The last step is to Promote the Work Item to the higher Org. A single promotion can include multiple Work Items, allowing them to transition together to the next environment.
Deployment:
- Click Promote – which should indicate ‘Deploy,’ as it is currently in the process of deploying to Production!
- Although deployment is ongoing, you can monitor it in your production org’s Deployment Status during this stage.
Deployed:
And there you have it, the Work Item has been successfully deployed!
Closed Stage:
After a successful promotion, the Work Item will transition automatically to the Closed stage.
Change Work Item Status to Never:
Sometimes plans change. At times, you may need to reset or resolve conflicts. If a change conflicts, removing files from the commit can ensure successful promotions of other work items. For these scenarios, you can set a work item status to ‘Never.’
When you change the status to Never, the work item becomes inactive, and the committed component files are returned to the list of available changes. You can recommit any of these files to another work item.
- You can change a work item’s status to Never before it’s been promoted into a pipeline stage.
- Changing the status to Never is non-reversible.
From the work item menu, select Change Status to Never, then click Confirm.
A Few Final Notes:
- This is a new tool, and additional features are still in development
- Currently, the only supported provider is Github. (Bitbucket, Azure & Gitlab will be available soon, but no firm dates yet)
- Classic Environments do not support DevOps Center
- Integration with ticketing systems like Jira/Azure is not yet possible
- There is a GitHub RoadMap for the Salesforce DevOps Center
Even with somewhat limited functionality, DevOps Center marks a massive improvement over Change Sets.
