Version Control For Salesforce — Branching Strategy

In the previous blog, we showed you how to setup version control & CI process in 5 minutes. Now, let’s discuss more sophisticated process flows.

One of the major challenges in adopting version control for Salesforce is the complexity around managing changes between git branches and multiple environments.

In this blog, we will go through three popular templates and discuss pros and cons of each so you can pick the right template for your team.

All templates assume that your team is using feature branching where each dev/admin works on his/her own sandbox and commit changes to a feature branch which represents a business change (jira ticket, business request, …).

Template 1: single master branch for all environments

Single master branch for all environments

Pros

  • Less branches to manage. Team spends less time on merge & conflicts.
  • Production is well reflected of UAT since they are both deployed from the same branch.

Cons

  • Inflexible. All features have to be accepted in UAT and moved to Production all at once. You cannot pick and choose features. This means production deployment can be blocked if there is a feature prolonged in UAT.
  • Require significant human coordination effort since you have to continuously evaluate release candidate in UAT and block your development pipeline closer to a production release.
  • Production release has to be done manually since there is no reliable automation trigger (because it is a business decision when to deploy)

Template 2: One branch per environment, one feature branch per feature.

One branch per environment, one feature branch per feature.

In the process above, uat is deployed from uat branch and production is deployed from master branch. uat branch is a superset of master branch. This means uat contains everything in production plus pending changes to be coming to production.

Following the sequence, users first commit to a feature branch based off master. Users then submit the first pull request against uat branch and wait for changes to be accepted in UAT before submitting the second pull request against master branch.

Pros

  • Flexible. A feature can stay in UAT for as long as needed. Accepted features can move to master/production independently without being blocked.
  • Deployment is fully automated. No human coordination is required.
  • Deployment is predictable. Anything that is accepted and merged to master will get to production the next day. This consistency is a key driver in making your team completely in sync and enable business change to happen fast. Adding a new field? Get your change to master today and it will be in production tomorrow.

Cons

  • Master branch and uat branch will eventually deviate.
  • uat branch and uat environment will need to be refreshed from master and production occasionally (monthly or quarterly)
  • Pull request PR1 is highly vulnerable to merge conflicts because we are merging from different baselines (feature_x_from_master branch merged on to uat branch). This is, however, isn’t a problem with the second pull request PR2. It is a trade off in keeping master branch clean as the expense of convoluting uat branch.

Template 3: One branch per environment, two feature branches per feature.

One branch per environment, two feature branches per feature.

This template is almost the same as template #2. The only difference is that we are using two feature branches per feature instead of one. While this looks complicated as first, it is actually more manageable in the long run because pull requests are least vulnerable to merge conflicts since we are merging feature branches against the same baselines (feature_x_from_master to master, feature_x_from_uat to uat).

Conclusion

Let’s evaluate the above templates against the following criteria:

  • Process should enable business to move fast without bottleneck.
  • Frequent (daily is best) release and small drops to production.
  • As little human coordination as possible.
  • Automate as much as possible.
  • Process step should be done in a declarative fashion so that less technical users (admin, business analyst, product managers) can participate without waiting on dev-ops engineers.

Base on the above, our recommendation, in order, is #3, #2 then #1. We also provide a video tutorial to help you getting started with setting up option #3.

The diagrams mark ClickDeploy features but this is no less applicable if you’d rather roll up your own tool sets.

ClickDeploy Enterprise is flexible and you can setup any of the above templates in minutes as well as evolve your processes in the future.

Leave your thoughts and comments below. We love to hear what works and what not for your team.

--

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Trias Weekly Report (Jun 15, 2020 — Jun 21, 2020)

Coding Apps for days!

DevOps | A Basic view of DC/OS and Containers.

Vim Extension for VSCode

DSLs VS APIs

Feature testability, as it applied to Kotlin tooling QA

Computer Science Books to Read

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
ClickDeploy Team

ClickDeploy Team

More from Medium

OFAC Checker: A modern OFAC screening tool for instant compliance check

Can’t get Diplo “[Off] My Mind”

This image is the album cover of “On My Mind”. It shows what appears to be a purple vinyl with the words “Higher Ground” at the top, “High 005” on the left, “33 1/3 RPM” on the right, and “Diplo-SIDEPIECE” at the bottom above the outline of a head with inside displaying an older video recorder with video tape reels. Below that are the words “On My Mind”.

How the Pandemic enriched 1:1s with Leaders

Quick Dictionary for a CSM