DevOps Center, a much-awaited feature, was officially released last June in Open Beta. This promising solution will enable change and release management, whatever team members’ abilities are on a developing scale, from low-code to pro-code.
In this article, we will be discussing how this new feature will impact the Salesforce ecosystem.
What is DevOps Center?
According to Salesforce, “DevOps Center makes the change and release management process when developing with Salesforce so much better. It allows you to take advantage of modern DevOps best practices through a centralized, easy-to-use interface”. DevOps Center has various relevant features, including automatic change tracking, a handy way of organizing your work, a GitHub integration, and a simple way of deploying your changes. All of these new additions will be explained in more detail further in this article. Salesforce is currently planning to implement a unified development approach across its platforms with DevOps Center.
How to Connect to DevOps Center
At first, accessing DevOps Center might seem a little bit confusing. In my case, I decided to create a new playground and go along the following steps:
First and foremost, decide what kind of org you want to use – sandboxes, scratch orgs, and playgrounds are supported.
After having made your choice, jump to your org and in the Home search bar, look for “Dev”. You will see DevOps Center pop up.
Select it, and you will be redirected to a screen that looks like this.
Make sure to enable DevOps center, and click the button below ‘DevOps Center is ready to install’ to obtain the new feature.
You will be prompted to a new page, in which you will be able to select the installation type.
It may take a while to install, so let’s move forward to the next step.
In order to access the DevOps Center, we need a Connected App. From setup, enter App Manager in the quick find search box. Select App manager, and click on New Connected App. Enter the following information in their respective fields:
Connected App Name: Devops center.
API Name: Devops_center.
Contact email: any email.
In the Web App Settings section, enter the following as Start URL: /sf_devops/DevOpsCenter.app
Save the new Connected App.
From setup, enter manage in the quick search bar, and select Manage Connected Apps. Find the newly created DevOps center app, click on it and go to Manage Permission Sets, in the Permission Sets section. Select “sf_devops_NamedCredentials”.
In order to finish the Setup, go back and click on Manage Profiles. Personally, I had to assign the profile System Administrator to gain access to DevOps Center, so if after trying all these steps you’re still not able to access it and you’re using a Trailhead Playground, consider giving it a try.
After having followed all these steps, you can go to your connected DevOps Center app and create a new project.
DevOps Center’s structure and data model are particular to its role as a release management solution. One of its more important elements, Releases, are developed and handled outside of the DevOps Center and contain any metadata changes that were made in relation to the business needs. One or more User Stories could be included in a release.
A User Story, which establishes the scope of the development activity, contains many business processes. Information gathered from user stories during the business analysis phase will help the development process be finished quickly and accurately. This information provides context, helps with understanding and maintenance, and lowers the likelihood of expensive reworks brought on by misunderstandings.
Moving forward, work Items are DevOps Center’s User Stories – they contain the list of metadata items that are pushed through a pipeline. A User Story can create many Work Items. They are a new object made for DevOps Center that can be used with standard Salesforce Flows and other operations to track and deliver the associated changes. When the work item is generated from the User Story, you link it to a Salesforce org. Additionally, DevOps Center creates a GitHub branch.
Then, you can retrieve a list of all metadata changes made in that Salesforce org and choose which ones you want to include in the Work Item you’re working on. Compared to creating a change set of one metadata item at a time, this approach is substantially faster.
The primary source control system is GitHub, however, Salesforce administrators do not need to be familiar with the CLI or GitHub. This might be the biggest change for admins, but it is important to keep in mind that it has been very simplified in order to make it approachable and understandable for those who do not know how to code or how the DevOps process works. All Github branches (including transferring metadata between branches) are managed by DevOps Center, together with Salesforce orgs.
The movement of work items, such as metadata updates, from the development stage to production is referred to as a pipeline.
In the case of DevOps Center, each stage in a pipeline is connected to a Salesforce organization. A stage could vary from different environments – such as a development sandbox or a scratch org. When advances are made, a Work Item can be moved from one stage to the next, via pipelines. You can create numerous pipelines, allowing you to determine the appropriate level of testing and resource allocation for each release based on different risks or criteria.
A replacement to Change Sets?
Previously, every time you wanted to push changes between orgs, you had to create a new change set and add all your desired metadata; you couldn’t just transfer a change set with all the metadata items. Change sets were a continual cause of wasted effort and frustration in releases, especially large and complex ones.
DevOps Center simplifies this process by providing version control, visibility over release pipelines, and overall a great boost in the development and deployment of your metadata, something that Change Sets couldn’t provide. Many developers work with external release management or ticketing tools (such as Jira or Azure DevOps) – with this new feature, you won’t require an additional solution to manage your Salesforce releases, and you certainly won’t need to use Change Sets either.
Salesforce Development’s potential in the future
Nowadays, the Salesforce platform is so much more versatile than it was years ago, and there is a great desire for customization. The addition of the DevOps Center is, together with many other new development features, a great achievement towards reaching Salesforce’s full development potential – a centralized tool in which you do not need to use external tools to create, design, and launch your new projects. In the case of release management, the DevOps Center tool comes as the perfect candidate for replacing Change Sets. Previously, we had no way of keeping track of the history of changes if we decided to deploy them via Change Set – unlike DevOps Center, where you can see a history of changes. The amount of work that teams are creating these days cannot be handled by the said tool – in big projects, using Change Sets can be a nightmare and a source of conflicts. DevOps Center offers a high level of coordination between team members, thus assuring the releases are a complete success. These are some of the many reasons why we need DevOps Center – a great development tool adapted to current rapidly changing times.
Personal and Final Thoughts
From my point of view, DevOps Center is an amazing free tool, which will be making the release management process a lot easier for many people involved in the procedure. However, DevOps Center is still lacking some relevant features, such as backup and rollback, and a ticketing system. Moreover, DevOps Center only has GitHub as its Source Control tool. Your developers will either need to switch to GitHub or wait for a subsequent edition that supports additional Source Control integrations if they currently use another source control system.
On top of that, you are unable to determine whether a metadata item is included in many Work Items inside a single release of a single pipeline or in various releases across various pipelines. As a result, determining the risk of boosting Work Items is difficult.
However, these limitations can be overcome with Partner extensions, since DevOps Center is built on Heroku and installed as a managed package. The first partner extension, DevOps Center with Elements, was introduced at TrailblazerDX ‘22. This extension overcomes most of the limitations and it can be installed as a managed package as well. It provides synchronization between Jira and Salesforce and a better view of the metadata across all Work Items for the purpose of conflict resolution.
In summary, in spite of a few limitations, DevOps Center is a promising feature that will make Salesforce Development and release management more approachable to different team members (such as low-code administrators) without making them uncomfortable with the process. Change Sets, a difficult, annoying, and time-consuming tool, is well-replaced by DevOps Center, especially when working on large projects. DevOps Center has a long road ahead and has already proven its worth by offering a smooth, centralized, and simplified release management process.