A simple Git branching strategy for Salesforce developers

As soon as your Salesforce implementation team grows to more than a 2-3 developers, you will find that deploying code to your Production environment become more challenging. Your managers gripe about the staging and production environments being so different. Your team overwrites each other’s work when pushing out features. Your team needs to start maintaining a spreadsheet of features that need to go out and makes sure that all of these changes are reconciled. The engineering team cannot identify when a particular change was implemented and for what reason. These are all signs of an ineffective deployment pipeline.

A better way to build code collaboratively is to add a version control system (ie – Git) into your deployment process. This will allow each of your developers to stay in sync with each other. It will make integrating changes into your Salesforce project a lot easier. Then, adding on a CICD pipeline tool like Copado or Gearset makes your code a lot easier to build, test, and deploy. Here is the easiest way to configure your deployment pipeline that works for most Salesforce implementation teams.

The System

First, setup your development team with their own development environment. Everyone in your team will have their own isolated development environment. The developer should be able to work on their solution from their own sandbox. Periodic sandbox refreshes will allow them to keep production and their sandbox synced with each other.

After the developer has finished his work in his sandbox, they will create a new feature branch from the mainline branch. This is what allows the new changes to be integrated with the rest of the team. The developer goes onto deploy the changes from his sandbox environment into this feature branch. Once the changes are all in the feature branch, the developer is able to login to Github and create a pull request.

The pull request allows the code review process to work. Now, another developer can review your work. This process is important and serves as a validation point. This also increases collaboration and teamwork within the team. After review, the other developer can either approve the change request or suggest additional work be done on the solution.

If additional work is required, the developer can go back to his sandbox and make the recommended fixes. They will then again push to the feature branch and create another pull request.

Once the reviewer and the developer are both satisfied with the changes, the feature branch will get merged with the mainline branch. At this point, the main branch is automatically deployed into a UAT environment.

The purpose of this UAT environment is twofold. First, this environment should resemble the production environment as close as possible. Second, it can serve as an area for user acceptance and performance testing.

Finally, on a scheduled cadence the team should agree that the latest changes in the main branch of production will be deployed to the Production environment. This can be performed on a manual basis.

Benefits of a source controlled system

This simple Git strategy will allow developers to rapidly deploy, discuss, and deliver code. You will see happier developers and change requests that can be built and deployed at a faster rate than ever before.