Every Salesforce DevOps engineer must have dreaded the infamous merge conflict.
My intent with this article is to bring clarity to the merge conflict topics: why and how merge conflicts occur, and how to solve them. Understanding these lets you handle them with more confidence!
Ideally, merge conflicts happen when people make different code changes to the same line of the same file, or when one person edits a file and another person deletes the same file. As frequent as it occurs, all merge conflicts must be solved before you merge a pull request on your source code repository (Example: GitLab).
As for Salesforce, the merge conflict has been a common pain point for enterprises implementing several cloud solutions in their Salesforce Org. There is always a list of common components like triggers and classes used across projects.
For example, assume a Sales Cloud implementation team customizing account trigger and its subsequent handler and helper classes. Within their own Development environment, the Service cloud team is concurrently working on the same set of components. In this case, there is a good probability that when the code from the Sales team is delivered to a Test or UAT environment, the changes that may have been previously deployed by the Service cloud team will be cleared out.
The most direct way to resolve the merge conflict and create a new merge commit.
Salesforce developers typically collaborate on the same projects concurrently. As a Salesforce developer, you frequently have to put in a lot of work to identify potential conflicts when integrating changes made by two developers in order to avoid code overwrites.
In order to do this, the team would have to spend a lot of time manually resolving GIT conflicts, which are difficult to integrate with Salesforce.
As the number of Salesforce developers grows, merging changes also gets more difficult, which reduces productivity. Additionally, change sets and ANT scripts do not offer a merging method, therefore developers do not receive this kind of merge conflict alert. A few more common reasons for conflict are:
Lack of DevOps tools: The DevOps team hasn't made any investments in a technology to automate or better orchestrate the git version control procedures.
Failure of branching strategies: Each branch that an engineer works on needs to have its own workspace for the code that specifies how it interacts with a common codebase.
No source of truth or the source truth being production metadata: Lack of a common process to combine data from several sources into a single repository so that developers can get insights
Inability of the existing tools to identify conflicts: If a DevOps tool has been used and the engineers are still having problems, this points to the failure of the tool to determine the conflict's underlying cause.
This is obvious, but an overlooked factor that occurs for your Salesforce environments as metadata differences between your environments begin to appear as you constantly deploy codes. When you have different environments such as Dev, QA, production, etc, you really need to make sure that they are as identical as possible.
Read more: Our detailed comparison of Salesforce DevOps tools: Opsera vs Copado
Branching strategies aren’t alike for all teams. Define how your team will handle the delivery of each feature, or bug handling without creating complexity in the delivery pipeline and leads to faster release cycles.
For example, consider a multi-branch approach to manage the source code. This approach consists of two main branches: master and develop. The production code is saved in the master branch of this approach, while development takes place in the later branch, where modifications are made and then merged into the master. For particular situations, support branches like feature, hotfix, and release can be built.
The benefit? A cooperative setting without codebase duplication
Implementing a DevOps tool can revolutionize the way you run Salesforce deployments. The Salesforce deployment apps have intuitive features to make deploying a breeze. A few benefits of using DevOps tools are:
Opsera offers powerful strategies to build perfect CI/CD workflows to automate your Salesforce deployments, allowing you to move your Salesforce code seamlessly between organizations.
With our configurable pipelines and out-of-the-box templates, you may designate workflows to metadata, objects, or classes between Salesforce Orgs, or Git to Salesforce, and develop pipelines with custom unit testing and code coverages.
Additionally, you may choose which objects, classes, and attributes to use as you deploy your pipelines. The opportunity to compare Salesforce orgs or Git and Salesforce org is also provided.
Here is an example of how Opsera displays a merge conflict when a task has been run.
You can create a Task (Git Merge Sync Task) to merge the components which would highlight conflicts between the source and destination, rather than overwriting files blindly.
Start by creating a Git Merge Sync Task by selecting the Salesforce components you wish to merge and the source file that has been modified. Any differences in the existing code and the incoming new changes will be highlighted for your reference. From here, you can choose to either ignore the changes or allow these changes to be merged into the destination branch.
You can resolve conflicts by using Pull Requests from code repositories as well. Find out more about resolving disputes in GitHub, BitBucket, and GitLab.
Merge conflicts can be an intimidating experience. Yet, as technology advances, the solutions are better. Pick an approach that satisfies and suits your organizational practices.
Check out this session “Keep Calm and Merge Conflicts” for an informative session and demo.
For more, explore our ongoing and previous events, such as our DevOps Huddles and Webinars where our experts discuss the challenges in the industry.
