Best Practices for Salesforce Version Control Strategy
What are the best practices for Salesforce version control strategy? Isn't it a common question among the Salesforce community? It seems like the Salesforce community is still struggling to get the answer right. The answer should be straight forward. Why should Salesforce not have the version control? But the data available shows a completely different picture. Even the most prestigious organizations are not using any version control and are relying on Sandboxes and team members to maintain code and configurations.
When asked about why such a basic process isn't being followed, there were mainly a few reasons given to defend the process breach. Most common answer pattern is that a smaller team does not need version control or Sandbox is our source of truth. These answers surely do not defend the problem. The real problem may have been deeply rooted in the way Salesforce is structured, which is configuration driving the functionality. Definitely, Salesforce is trying to address this problem using Salesforce DX which is giving results pockets, but the adaption of DX and further implementation of version control is still an unexplored area. Based on the survey and analysis, the root of this problem is the lack of automated tooling around code promotion.
In the absence of such tooling, developers develop on Sandbox and move the code and artefacts to various Sandbox environments. Another question here is, how are we solving this problem and bringing the engineering hygiene to Salesforce ecosystem? To answer this, we take a scientific approach towards implementing version control for Salesforce. This approach not only provides guidelines but also helps implementing version control tool of choice for any size of teams. This approach offers a complete success package for version control implementation along with Sandbox usage strategy, end-to-end deployment automation tools and static code analysis tools.
Source code version control brings governance and transparency to the engineering process by:
- A change history that is visible to all team members.
- Ability to alert developers if there is a code conflict.
- Achieve environment consistency with dynamic, repeatable deployments to every environment.
- Enforcing test classes to be run in Sandboxes so that test class issues can be discovered at an early stage.
- Allow weekly (possibly daily) deployments (continuous integration and delivery).
- Ensure that the release management team can manage deployments.
Implementation of version control for Salesforce is a scientific process that can be executed on a step-by-step basis. To start with, a baseline source code or source version should be defined. Typically, this version can be retrieved from the production ORG and treated as the base version. This step is very important since developers have the habit of keeping their current versions at various places and starting with correct base line version can be tricky at times. Hence, the best way out is to use whatever is in production as the baseline code.
At this point, many organizations may pick and choose and possibly argue about the best version control software that one should be using. The next article would talk about comparison between various version control tools. As a thumb rule, choosing version control should be an organization-wide decision based on the number of users, locations, type of source code, number of parallel tracks, interdependencies and many other factors.
Let us now discuss about the approach of branching and merging strategy. Here, the decisions are purely based on how many parallel tracks or development streams are going on and also what are kindly release cycles and parallel phases that the teams are executing at any given point of time.
In a typical branching and merging pattern, each development stream can have its own branch and at the end of development phase, this branch gets merged into the release branch, where all Quality Assurance (QA) and User Acceptance Testing (UAT) is executed. Production build and hotfixes are also promoted from the same release branch. They vary from different types of sub projects of this strategy.
To enable version control success, project team should follow certain disciplines and rules where only the source files and configurations are treated as “source of truth” and are checked in into the version control software. The pieces of code that are not checked in are simply not considered. To conclude, the tooling around the version control will help achieve repeatable success, error free code management and engineering process efficiency.
What are your thoughts on version control strategy?