Version Control For Salesforce — Branching Strategy
Git Branching Strategy & Environment Management Best Practices.
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
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.
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.
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.
