�ֲ���ýapp���°汾

If you have worked as a Developer (Pro-Coder) or a Declarative Administrator (Low-Coder), you know that Merge Conflicts are always a risk.

Take a simple Salesforce page layout, for example. If you are editing a page layout in Salesforce at the exact same time that another Salesforce user is editing the same page layout, one of you will get an error upon save that the version of the page layout has been changed by another user.

That is a merge conflict, directly in the Salesforce platform.? The �ֲ���ýapp���°汾 1 Platform provides multiple features to enable merge conflict resolution with Git (Version Control) ( and ), but the goal of this blog post is to make recommendations for proactive merge conflict prevention, through process.

Here are 5 Best Practices for Merge Conflict Prevention

• Scrum Planning - Minimize User Story Metadata Overlap within a common development period (e.g. a Sprint).
• Say, for example, the theme of the current sprint is enhancing?the Sales Team��s opportunity pipeline management. You may assign?developers and declarative administrators to work on new fields and new or updated Salesforce automations (SFA).
  But for the components with broad interdependencies, such as Layouts, Lightning Pages or Permission Sets, and perhaps even complex, multi-object Apex or Lightning Web Components, consider assigning a dedicated contributor to mitigate overlap and minimize the risk of merge conflicts.
• Inter- and Intra-Squad Collaboration - Proven mitigators to merge conflict prevention are awareness, communication and collaboration.
• Sometimes user story metadata overlap is simply unavoidable; however, awareness, communication and collaboration amongst the DevOps squads and team members are not.
• Encourage and facilitate opportunities for the DevOps squads and team members to discuss planned work for the upcoming sprint, taking care to discuss known overlap and its impact, and to collaborate throughout the sprint to minimize the risk of merge conflicts.
• Be mindful that two different Squads may overlap, even if they are dedicated to different groups of business users all utilizing the same Production Org; standard objects like Accounts and Contacts may impact many other metadata components in the common Production Org.
• Strive for traceability of discrete metadata changes back to the documented functional requirements on each user story, which will also help raise the visibility of overlap.
• Leverage Quality Gates designed for proactive Merge Conflict Prevention - for example, Git Pull Requests and the �ֲ���ýapp���°汾 User Story Overlap Awareness feature.
• Both the feature and the feature provide teams the opportunity to proactively identify potential merge conflicts and make decisions about how to ultimately avoid them, either through redesign or via coordination and separation of DevOps duties.
• Back Promote early and often - Consider the below sample pipeline and the fact that work-in-progress from the four lowest environments get merged as it is promoted/deployed up to DevMerge.
  
  

• Leverage with a single (default) Connection Behavior or discreet (override) Connection Behaviors with Scheduled Back Promotions or with Scheduled Back Promotion Automations to ensure the lowest environments are kept in sync with one another and to prevent merge conflicts for unknown changes from other contributors.
• Ensure that all DevOps team members are aware of the back promotion schedule so that they have an opportunity to commit to work in progress in advance of the scheduled back promotion.
• If individual DevOps team members prefer to manually retrieve the back promotions of changes from other contributors, strongly encourage them to do so on a frequent and regular cadence. Waiting to back promote until stories have passed QA or UAT introduces a higher risk of unexpected changes from other contributors causing merge conflicts with your own work-in-progress.
• The same recommendations apply to Hotfix. Since the intent of Hotfix is to be an emergency recovery environment when a high-priority defect is introduced into Production, it is important to ensure that Hotfix is as closely synchronized with Production as possible.
• Finally, given the fact that all feature branches are typically created out of the main/master branch, it is also important that any Hotfix changes promoted/deployed to Production are rapidly (ideally, automatically) back promoted down to all lower environments, not only to mitigate merge conflicts, but also to help inform so that new work-in-progress coming up the pipeline does not conflict with, or worse, overwrite, the Hotfix changes in the upper environments.
• Monitor, Assess and Revise Processes - DevOps is a cyclical evolution; it is not linear.
• DevOps teams are encouraged to monitor and review their DevOps outcomes, for example, to identify environments with the highest occurrence of merge conflicts and determine a go-forward plan for further merge conflict prevention.
• The free �ֲ���ýapp���°汾 Labs reports pack includes a report of merge conflicts by destination environment and is an easy way to identify the environments in the pipeline with the highest frequency of merge conflicts.

Conclusion

DevOps and Merge Conflict Prevention are no different than driving a car on a busy highway in the snow. We can have all the top-notch tools (paved roads, well-marked lane lines, guardrails, snow tires, seatbelts, speed limits). But if the drivers on the road do not follow best practices and have good driving processes (obey the speed limit, signal when changing lanes, follow at a safe distance, turn on your headlights when visibility is compromised), then there is a far greater likelihood of a collision.

The �ֲ���ýapp���°汾 1 DevOps Platform includes an integrated set of products and features to not only support your technology but also enable people and processes.

What��s next?

Review the �ֲ���ýapp���°汾 User Toolkit Webinar Series for additional recommendations, for example, �ֲ���ýapp���°汾 User Toolkit Episode 2: Eliminate Merge Conflicts with Back Promotions.

About The Author

Jen Nelson is a 20-year veteran of the Salesforce ecosystem, a current Salesforce MVP Hall of Fame member and has 30+ years experience in DevOps. Jen has been with �ֲ���ýapp���°汾 for 4 years and is the Director of Product Technical Enablement.