Branching Strategies For Salesforce Version Control
Branches are independent lines of work that stem from a single central code base. Today, most Version Control Systems (VCS) support branches. Depending on your VCS, the main branch may be referred to as master, default, mainline, or trunk. Developers can create their own branches from the main code line and work independently along with it.
Why is Branching Important?
Branching enables teams of developers to easily connect with one another inside a single central code base. When a developer creates a branch, the VCS creates a copy of the code base at that point in time. Developers can easily integrate changes from other developers to sync up with features and ensure their private branch doesn’t stray too far from the master. Any changes a developer makes to the branch will not have an impact on the work of other developers on the team. This is a blessing because the features under development can create volatility, which can impact all the work if it were happening on the main code line.
Three Branching Strategies for Agile Teams
Branching models often differ between teams and are an issue of much debate in the software world. A major point of contention is what amount of work should remain in a branch before it gets merged back into the master.
It refers to the idea that a release is contained entirely within a branch. This means that later in the development cycle, the release manager will create a branch from the master (for instance, 1.1 development branch). All changes for the 1.1 release have to be applied twice: first to the 1.1 branch and later to the master code line. Working with two branches is additional work for the team and it may, sometimes, overlook merging to both branches. Release branches can be cumbersome and difficult to manage as multiple people work on the same branch. If you have to do a release branch, then ensure that you create the branch as close to the actual release as possible. Release branching is an important part of supporting versioned software in the market. A single product may have multiple release branches (e.g., 1.1, 1.5, 2.0) to support sustained development. Changes in previous versions (i.e., 1.1) may have to be merged with later release branches (i.e., 1.5, 2.0).
Looking for a more flexible branching model, many agile teams have migrated from release branching to feature branching. A feature branch model keeps all the changes for a particular feature intact inside a branch. After the automated tests fully test and validate the feature, the branch is then merged into the master.
Feature branches are often integrated with feature flags, which enable or disable a feature within the product. That makes deploying code into the master a cakewalk and enables controlling of a feature when it is activated, making it easy to initially deploy the code, well before the feature is showcased to end-users. Feature flags also ensure that the code, while in development, can remain inactive within the build. If something goes wrong when the feature is enabled, a system admin can turn back the feature flag and get back to a former good state, rather than having to deploy a new build.
3. Task Branching
Every organization has a natural way to break down larger work into individual tasks inside an issue tracker, such as JIRA software. Issues then become the team’s central point of contact for that piece of work. Task branching is also known as issue branching, and it directly connects those issues with the source code. Each issue is implemented on its own branch, with the inclusion of the issue key in the branch name. It’s easy to identify a particular issue a code implements: you just have to scout for the issue key in the branch name. With such level of transparency, it’s easier to apply focused changes to the master or any longer lasting legacy release branch.
Since agile pivots around user stories, task branches sync up well with agile development. Each user story (bug fix) lives within its own branch, making it easy to view the issues in progress and those that are ready for release.
As you create future releases, it is a good idea to try to migrate older customers onto newer branches to reduce the potential number of branches you might have to patch up to fix a bug issue.
Using this technique, you can deploy solutions using your technology to a range of customers who require different levels of service. You can also segregate your current deployments from dangerous new code in the trunk, with the worst merge scenario being a single branch.
How AutoRABIT Can Help You with Version Control
AutoRABIT has some very powerful capabilities that can help Salesforce development teams get onboard and streamline their development process with Version Control System. AutoRABIT can help in setting up a central GIT repository. After creating a central GIT repository, the master branch will be populated with metadata from production. This is done by committing all the metadata folders, along with the Package Manifest file, to master branch and pushing them to remote repository.
AutoRABIT commits the developer’s changes by updating the folders and package file. In other words, the changes will be committed to the developer’s local repository. AutoRABIT also allows you to merge multiple branches and you don’t have to make changes in that particular repository, since any change in AutoRABIT will be reflected in the particular repository branch and vice-versa.