Salesforce has become the leader of CRMs for many reasons, including the ability to customize the platform itself, allowing a full adaptation to each customer’s needs. These customized developments have in turn enabled Salesforce to know on how to improve its technology. Now, one of its greatest novelties is Salesforce DevOps Center, and S4G Consulting is here to point out which features and use cases you can apply to get the most out of it.
What is Salesforce DevOps Center?
It is a new Salesforce product that improves the change and release management process when you develop with Salesforce. It also helps leverage DevOps best practices through a centralized and easy-to-use interface.
- Teams can track and deploy changes associated with a specific functionality in a few clicks, thanks to the new Work Items object. These can be operated with Salesforce Flows and other platform operations.
- As teams make changes to their sandboxes, these are automatically tracked. DevOps Center provides an interface for viewing a list of changed metadata components, as well as the option to select the ones we want to promote or discard.
- Create intermediate stages of integration, validation and testing to ensure quality and efficiency of new product releases.
- Integration with GitHub (Git version control platform) to centralize source code changes developed by technical or functional profiles is easy, done in a friendly manner for those who have no experience with Git, branch management, or Pull Requests.
- Centralize your management with easy-to-use visual tools to follow the best DevOps practices, both at technical and functional level.
Benefits of DevOps Center
The main benefit of Salesforce DevOps Center is to minimize dependency on functional profiles with technical profiles. In other words, it is not a requirement to have knowledge of Salesforce CLI or Git to manage changes, versions or promotions of Salesforce custom functionality.
This benefit is leveraged by team leaders who use current DevOps practices to increase deployment frequency, reduce average incident resolution time, and minimize change failure rate.
Another benefit that DevOps Center offers is to provide technology teams with a simple and transparent development process, which promotes greater visibility and traceability throughout the lifecycle of feature changes to be promoted.
Why has Salesforce created DevOps Center?
Customization within the Salesforce platform has been improving with the implementation of Salesforce DX (SFDX) as well as Salesforce CLI. All of this has allowed it to integrate gradually with Git and, at the same time, it has changed the paradigm of “source of truth”. That is, it has evolved from Salesforce sandbox to Git Repository.
Salesforce CLI and Git were developed for technical profiles, which are autonomous when it comes to managing changes, releases and promotions. However, there are functional profiles that rely to some extent on technicians to promote their changes if they do not want to replicate them in each upper environment.
Today, many projects continue to use ChangeSets for price reasons or because they are not overly complex. ChangeSets has been used for a long time and functional resources are trained or made to promote their changes to higher environments. Nevertheless, the same projects evolve but ChangeSet falls short and often does not cover the project’s needs.
Therefore, DevOps Center was developed for the general purposes of:
- Reducing the complexity of collaborative implementation in real time.
- Bridging the gap between technical and functional developers, i.e. minimize dependencies on technical developers to work with the Git Repository and Salesforce CLI.
- Evolving ChangeSets to meet complex project needs.
- Accelerating developments and deliveries while maintaining the good practices of DevOps methodology.
How does DevOps Center work?
DevOps Center consists of three bases.
- It follows an agile methodology that is based on user stories, which can contain N lines of development.
- Each development line will be directly associated with a source Salesforce environment.
- You have a target Salesforce environment, where these work lines are promoted.
Each developer, technical or functional, can work in isolation on your copy of the PROD sandbox and, after completing their changes, automatically promote them without writing any SFDX or Git commands.
When developers work on their development sandbox, their changes are unique and can be automatically synchronized with Git by pressing buttons from the interface offered by DevOps Center. The actions that trigger these buttons are:
- Create feature branch.
- Save changes to feature branch (commit).
- Publish feature branch with changes in repository (push).
- After completing the development line, you can promote your changes, which behind generates a Pull Request towards the target branch.
- By promoting changes, DevOps Center is synchronizing target branches (merge) and deploying metadata in a target Salesforce environment. This is done automatically and transparently to the developer.
The essence of DevOps Center is to provide the ability to extract all changes from the nominal environments to the Git Repository without the need for Git commands, as well as to deploy those changes to a target Salesforce environment without the need for SFDX commands. This facilitates the independence of functional developers, i.e. declarative.
How does it interact with a developer?
A developer can be technical or functional. But for DevOps Center this distinction is minimal, as it provides all the tools needed to follow DevOps best practices.
Let’s see in the picture that in both cases (functional or technical) the guidelines that a DevOps methodology should follow are met.
Depending on the pattern we are in, we may execute the following functionalities provided by DevOps Center:
Work Item: Defines the change requirement to be made and tracks associated metadata source files throughout the release lifecycle. Work Items increase visibility where the changes reside at each stage of the pipeline.
Conflict management: Identifies work items that have conflicts with other work elements in the production chain. Provides information to help us resolve the conflict.
Development Environment Synchronization: Detects when a development environment is outdated, forcing us to update and make sure we are working with the latest source of truth. It informs us of the differences and allows us to synchronize to avoid future conflicts.
Activity history: Provides greater visibility, auditing, and error tracking in the Work Items view.
Metadata can be removed: It allows us to delete components in the target Salesforce environment, avoiding conflicts or validation errors or deploy.
Validation only deployments: Allows to execute a validation-only deployment and, later, make a quick deployment.
How do I get DevOps center in Salesforce?
It is currently available for productive PE/EE/EU environments. This means that all management runs from within PROD and therefore all developers must have access to it.
To install it, simply activate the “Enable DevOps Center” option, install the package, and configure the Developer and Release Manager roles. As they explain in the official guide.
When to use DevOps Center?
Depends on several factors and the most important factors to decide whether to use DevOps Center or not:
- Analyze team maturity with DevOps methodology: Because some projects may be burdened with very complex functionality that DevOps Center cannot handle.
- Assess whether changes executed in source code correspond to complex files: Profiles, Flows, Permission Sets, Layouts, or Custom Label. These files have a high probability of conflict, which cannot be managed by DevOps Center and the main reason that it cannot be managed is that it does not provide an interface to prevent conflict.
- Analyze on which Git platform the Salesforce project exists or will be developed, since DevOps Center currently works with the GitHub platform.
What options exist if I cannot use it?
There are currently several market tools such as Copado, GearSet, etc. However, sometimes we may not need all the closed functionalities of the available market tools, which means saving costs.
In S4G we have experience with DevOps methodology, which has allowed us to develop our own Salesforce deployment tool called “DevKops CI/CD”. It covers our needs, which are the most common in Salesforce projects. But if you still have any questions about what’s new with DevOps Center, do not hesitate to contact our team.