Salesforce DevOps

The Untold Truth about Git with Salesforce

Why Salesforce DevOps is more than just hooking up a git repo to a Salesforce org

Harry Williams

October 21, 2022

Table of Contents

FREE TOOL

Profiles & Permissions Deployer

Easily compare and deploy Profiles, Permission Sets, and Field-Level Security (FLS) between any two Salesforce organizations.

Get Started

Made with love by the Blue Canvas team ❤️

The term DevOps encompasses so many expectations and so much tooling nowadays that a simple question such as ‘Is my team doing DevOps?’ can lead to wildly different answers depending on who you ask. In the worst case this leads to unfulfilled expectations: you think you’re increasing velocity because you’ve set up a ‘DevOps tool’, when in reality you’re still constrained by lagging functionality or uncovered use-cases.

Source code versioning is a great example of DevOps functionality that can still fall short. With the increased popularity of DevOps for Salesforce, there are now plenty of solutions for hooking up an org to a git repo. But that’s just the tip of the iceberg: sure you might get a revision history, but are you truly able to seamlessly merge work from different sandboxes? Let’s dive into the nitty gritty of what it really takes to enable a DevOps workflow in Salesforce!

The appetizer: Salesforce change history and rollbacks

The beauty with Git is that the minute you set it up in your workflow (and embrace the notion of committing), you immediately gain out-of-the-box benefits. This includes:

A thorough history of changes across your files/data (a.k.a. the commit history)Comparing versions in just a few seconds (a.k.a. doing diffs)
Rolling back to a previous version with just a few commands
Apply that to the Salesforce world, and provided your sandboxes are synced to a git repo, all of a sudden you can review changes to your Salesforce metadata at a glance, compare sandboxes, and eventually roll back recent deployments more seamlessly if you need to.

Compare that to where the community was when Change Sets were the only option, and you’ve made leaps and bounds forward already in terms of developer tooling and experience.

History of changes in my sandbox. Git-powered!

This ability to thoroughly track changes over time already proves very convenient to dev teams. It’s your backup and complete history in one place, all separated in small, bit-sized changes from individual devs. It gets more tricky when you look at the work currently ongoing: multiple devs may be working on the same feature, in overlapping sections of the code. Consolidating and deploying such changes smoothly requires more complex functionality, and leads us to talk about merging.

The main course: Git merge for Salesforce (when teamwork makes the dream work!)

At Blue Canvas we’ve heard too many Salesforce teams share their frustrations about ‘good enough’ git tooling that was letting them down any time developers would submit conflicting changes. Different tools can show different behaviors:

Some explicitly fail and let the end-user diagnose and resubmit a change
Some can totally overlook the fact that there even was a merge conflict, and in such case silently overwrite one of the existing code changes

The typical scenario involved looks like this:

Merging changes from Salesforce orgs

This is where merging comes handy. If you’re familiar with Git it’s likely one of the features you benefit most from. If you’re however new to it, then merging is a concept which might still be hard wrapping your head around. The documentation for git-merge alone demonstrates the extent of the topic (showing conflicts; resolving them; merge strategies…). While it may be overwhelming from a technical standpoint, functionally the implications are pretty clear:

If no merge conflict detection is in place, there is absolutely no safeguard against a developer overwriting another developer’s work without even noticing
In a Salesforce context, having individual sandboxes each connected to a git repo contributes nothing specifically when it comes to consolidating work done on these separate sandboxes
Being able to consolidate work from different developers and sandboxes, also means your DevOps tooling must be able to determine the common denominators (common ancestors in git terminology) between those separate working environments

This set of problems is why Salesforce DevOps is more than just hooking up a git repo to a Salesforce org. A reliable git workflow requires a proper merge conflict resolution functionality in place. One that both warns the dev team when a conflict is arising, and also one which guides developers in pushing the expected (and safe) code to UAT and production.

At Blue Canvas we believe that solving this problem is at the crux of enabling ‘DevOps for Salesforce’. It is what will truly enable teams to collaborate together in one same Salesforce environment, with multiple developers that can each work in their own sandbox, and then reliably and efficiently combine their work together to deliver features in production.

A pragmatic approach to reducing merge conflicts

It’s a common saying in software engineering that ‘there is no silver bullet’ and we believe that this totally applies to improving git workflows as well. Having received feedback from companies and organizations of all sizes, we’ve quickly realized that various features can actually help on the ‘team has conflicting changes’ problem. Some concrete examples which we've implemented over time:

A dedicated UX for reviewing diffs and commenting on them: this allows teammates to casually raise the hand and notify of a potential conflict with what they’re working on
Quick Sync between Salesforce and your git repo: the less time it takes to sync Salesforce changes to your git repo, the earlier you are made aware of potentially conflicting changes that you need to incorporate first
Overall tool performance: the faster your devs can compile and submit code changes, the likier it is that they will frequently submit small snippets, instead of bigger chunks that have mores chances of clashing with other changes

Review early, review often, so the team is continuously on the same page - Blue Canvas screenshot

All in all this is a continued focus on enabling teamwork and reducing time to deploy. 🚀 More can be done of course, including on that specific merge solving problem. By the end of the year we will announce a new Blue Canvas feature, introducing a revisited git integration that allows for complete 3-way-merge detection and resolution straight from our deployment UX. Less last-minute surprises, more control over your code changes, and a (once more!) sped up deployment! Stay tuned as we will update you on the latest.

Final thoughts

This blog post is the first of a series where we will regularly update about our milestones in offering top-notch git source control for Salesforce Teams. You can already read about our recent efforts in reducing sync speed to less than a minute between a sandbox and a git repo, which as we mentioned in this post is a foundation to more advanced git functionality.

In the meantime we invite you to sign up for free already at https://accounts.bluecanvas.io/signup. Just connect your orgs, compare them in seconds, and speed up your deployment workflow . We hope you’ll love the experience, would be thrilled to get your feedback, and look forward to delight you with more new features this year. You can stay in touch by subscribing to our Newsletter, or following us on Twitter @bluecanvasio!

EDIT: our next blog post on Salesforce+Git is now live! Read about Why merging is the hardest part of integrating Git with Salesforce

Best,
The Blue Canvas Team

‍

Try bluecanvas now!

Start your 14-day trial!

Get Started

Made with love by the Blue Canvas team ❤️

Try Bluecanvas now!

Start your free 14-day trial

Get Started

TABLE OF CONTENTS