Best Practices

Feature Branching in Salesforce

Deploy faster and with fewer errors with feature branching.

Harry Williams

October 7, 2019

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 ❤️

Feature branching is a concept that is used in most software development environments. If you’re working in .Net, Java, Python, Go, Node.js or Ruby you are likely familiar with the concept. Instead of making changes to the code base directly, you can branch off from the mainline and work on a specific feature in an isolated branch. This allows multiple people to work safely on the same code base in parallel. Atlassian recommends it in their Git flow for Salesforce guide.

Wait, Isn’t This What Sandboxes Are For?

Salesforce promotes a similar but different concept with their sandbox offering: instead of making changes in production, make them on a sandbox first. Then merge the code changes back into production only when ready. This is a great concept but it doesn’t quite solve the same problems as feature branching.

Faster, simpler deployments are the key to feature branching in Salesforce.

First, sandboxes tend to be staging environments rather than isolated units of work. On a sandbox there maybe dozens of features going on at any given time. And there may be multiple developers making changes to the same code base causing code clobbering and related havoc. We have seen sandboxes that have not been synced with production in over a year. So the dependencies between sandbox and production are likely to be out of sync making merging difficult.

Feature branching takes the sandbox concept to a whole new level. This blog post will provide a more in depth look at why your team should be actively using feature branching for Salesforce and how to do it.

What is Feature Branching?

You may find yourself thinking “I’m just a Salesforce developer or admin. I don’t have time for all these complicated Git processes. What is in it for me?”

The idea is that all feature development work should be done in isolated branches instead of on your master branch has myriad benefits for Salesforce developers and admins:

Developers can experiment with features without disturbing the main code base.
Different features can be treated as different bits of work and released on their own schedule.
Your mainline branch never contains broken code and is always deployable meaning you can ship more frequently. This makes end users happier instead of large sweeping changes.

Also, it makes deployments much faster. Your development branch is never too different from the mainline branch because you are doing small independent units of work, making merging much simpler. Imagine a sandbox that has been newly created. You make a few changes on the sandbox and then deploy a changeset that afternoon. It’s likely to go smoothly because there wasn’t enough time for dependency differences to build up between your sandbox and production. Feature branching allows the same concept.

Feature branching also makes the concept of Pull Requests or Deployment Requests possible. This encourages code reviews for Salesforce and discussion about particular changes before doing deployments.

If you use feature branches you will:

Deploy faster and more frequently
Deploy with fewer issues
Introduce fewer bugs
Get rid of code clobbering
Have small units of work that you can rollback easily

This is helpful for all members of a Salesforce development team who are overworked already.

How to Feature Branch

To use feature branches with Git you need to know a few commands. You will want to start with the mainline branch, typically master:

git checkout master
git fetch origin
git reset --hard origin/master

This moves you to the master branch and pulls any changes from master that are on the origin remote.

You can create a new branch for your feature:

git checkout -b my-feature

This command creates the feature branch called my-feature and checks it out at the same time. The newly created feature branch should be exactly the same as master at this point. You can now make changes and commit them to the feature branch like so:

git status
git add .
git commit -m “my commit message”

Now the change is committed to the feature branch. Now we can do one of two things: we can merge it directly into master or we can create a pull request. Creating a pull request is a good idea because it gives colleagues a chance to review the code before merging it into master and then production:

git push -u origin my-feature

origin is the name of your Git remote repository. my-feature is the name that you want to give the branch that you are going to create on that remote. Generally, you want to use the exact same name that you have used locally to avoid confusion.

Then, if you are using Bitbucket, GitHub, or Gitlab you can use their pull request technology and open a new pull request. They have tools for code reviewing and merging through their user interfaces.

What Makes Feature Branching in Salesforce Difficult

Feature branching has been historically difficult for Salesforce. For one, very few teams are using Git at all. And feature branching requires some Git expertise and command line familiarity. Salesforce developers may have no problem with this, but when a project includes, consultants, admins, product managers, project managers, business analysts and others, it becomes difficult to expect everyone to master Git from the command line.

Most teams are using sandboxes as a kind of semi-feature branch. However, Sandboxes are slow to spin up and cumbersome.

Deploying with change sets or Ant scripts are difficult. This makes the merging of a feature branch back into the mainline tedious. No one wants to do this too often so teams are settling for monolithic changes and releases that span weeks or months. Furthermore, it is not uncommon to have your Git code and your production code reflect different truths. Often times something that is pushed to Git is not deployable to production because of dependency issues.

Because teams are having multiple users develop and configure on a single sandbox, merge conflicts come up frequently and are not easily dealt with.

New Technologies Make It Easier

Blue Canvas makes feature branching much simpler for Salesforce developers. In four clicks, you can tie a branch in Git to an org without ever touching the command line. All changes on that branch are automatically committed into Git. You can issue pull requests from the Blue Canvas UI which allows for code reviews and code merging if the review is accepted.

Not only does Blue Canvas help with the branching, it helps deployments. And faster, simpler deployments are the key to feature branching in Salesforce. If you can deploy selective components quickly it makes more sense to treat each new feature as its own branch. We even just released branch deletion so you can wrap up a branch when you are done.

Salesforce DX and Scratch Orgs

Salesforce DX makes feature branching for Salesforce even more possible. DX introduces the concept of scratch orgs. Scratch orgs are sandboxes that can be spun up in minutes rather than hours or days. They persist for only about a week and so are perfect candidates for feature branching.

Blue Canvas is developing new technology to make feature branching with scratch orgs easier and more accessible without using the command line. With Blue Canvas you can spin up a scratch org from the UI, and it gets automatically tied to a branch.

If you want to check out feature branching with Salesforce DX and Blue Canvas, email team@bluecanvas.io to setup a trial.

‍

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