What Is Knowledge of Branching Strategies in the Context of a Build/Release Engineer or DevOps Engineer Job Description?

Problem scenario
You are preparing for an interview for a job where a requirement is "knowledge of branching strategies." What could you discuss to assure them that you have knowledge of branching strategies?

Solution
Code versionin systems can be referred to as SCMs (Source Control Managers) or VCSes (Version Control Systems). Some companies have big development teams whereas others have small teams. The internal dynamics may dictate whether or not you will create a branch of a source code repository or not. Naturally you should be the flexible type of person who can work according to how the company tells you. If your professional position will determine the branching strategy, now in 2019, there are two basic options for the sake of simplicity. (There are more options than these. But this answer would have been different if it was written in 2015 when jobs did list "knowledge of branching strategies" back then too.)

One option is "trunk-based development." The DevOps Handbook cites Gary Gruver (on pages 144 and 145), and his success with not having another branch. Trunk-based development is the lack of a second branch. Forking a repository is creating a second repository; it is like cloning one but "fork" connotes the publication of an independent copy of a repository. A branch is an independent copy of a repository within a repository for the purpose of possibly merging it with the trunk. To develop in a mainline way is another phrase that describes trunk-based development. It can be worthwhile to forgo a branch for a single-source of truth. It can deter developers from committing code without a significant amount of work. They may do more testing before they commit their code. This strategy may be accepted by the business if there is little to no need for an approval process; some development projects lend themselves to this. Code versioning systems by their very nature preserve archived versions, thus trunk-based development may work for numerous businesses. It is ideal for small teams.

To learn more about trunk-based development, you may want to read these links:
https://paulhammant.com/2013/04/05/what-is-trunk-based-development/
https://trunkbaseddevelopment.com/

A second option is to have branches. A branch to a repository can be ideal in a large team with a new developer. A new developer can aggressively refactor code to correct a bug or add a new feature. Before all the parameter files and source code are merged (and thus overwrite) the existing files, he/she can create a pull request. This is a request which will enable another person (e.g., a more tenured employee who knows the businesses coding conventions and idiosyncrasies) to approve the merge of code manually. Companies with high turnover and large numbers of developers may prefer to have branches of repositories. Code repositories have archived versions of the code. Thus some companies find a formal code branch merging approval process tedious. The DevOps Handbook extolls the benefits of having a single code repository as opposed to two or more.

The benefits of having a shared single source of truth are many (and described in detail in The DevOps Handbook on pages 290 through 292). To generalize the benefits of an accessible repository that numerous professionals can work on, we can see how "trunk-based development" has its place (without extra branches which can be confusing for parallel development of code). A code commit to a repository could be the impetus for the CI/CD process. With automated testing, the promotion of the code to higher environments will happen safely. You can have more testing, in theory, with trunk-based development.

Having branches can be an alternative that can be an efficient way for programmers to collaborate. A developer can merge code changes to a number of different files with an approved pull request. The submission of a pull request will send a notification that a request for approval of the code changes has been made. The approver will see the changes via the diffs. This can be an efficient way to collaborate with clear ownership of code before it is integrated.

The DevOps Handbook (page 186) cites Paul Hammant who gives mixed treatment toward trunk-based development. Paul Hammant, depending on the circumstances, can recommend "branching by abstraction" (a term he coined) which can facilitate a hybrid approach to development (a mix of trunk-based development with branches to source code repositories) (page 186 of The DevOps Handbook). Different branching strategies have their place depending on the environment, the team size, the goals, and how formal the approval process is.

To learn more about Git branching strategies, read these articles:

https://www.creativebloq.com/web-design/choose-right-git-branching-strategy-121518344
https://nvie.com/posts/a-successful-git-branching-model/
https://gitversion.net/docs/git-branching-strategies/
https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows
https://medium.com/free-code-camp/an-introduction-to-git-merge-and-rebase-what-they-are-and-how-to-use-them-131b863785f
https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=vsts
https://stackoverflow.com/questions/2428722/git-branch-strategy-for-small-dev-team
https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/
https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2

This git command "git bisect" is relevant to reconciling different branches:
https://git-scm.com/docs/git-bisect

To view a list of books, see this page.

Leave a comment

Your email address will not be published. Required fields are marked *