1 Branching Model

A Branching Model is a representation of a branching structure followed in a project’s SDLC. A branching model may comprise of one or more than one branches, and the workflow of the branching and merging would depend on the Software Development Methodology used by a project or an organization.

1.1 Various types of Branches

Branches can be of various types and names which may be created to serve different purposes. Few of the most popular Branching types are listed below:

• Main branch: It is ideally the most stable branch which has the latest production code in it. No coding and development is performed here.
• Release branch: The release branch is drawn out from the Main branch which has the latest production code i.e., code of last successful release. It contains the version one is currently locking down prior to the new release. Development will be very minimal or not at all on Release branch.
• Develop branch: Develop branch is drawn out from the Release branch and is the one where actual development code is stored. Developers do their required changes here and nightly builds are performed on this branch. Code is deployed to lower environments and the software is tested on its quality, performance and functionality.
• Feature Branch: Feature branches are evolved when a specific feature development is required and sub-teams are organized to work on the specific features independently without disrupting another team’s work. The feature branch usually exists until the specific feature of the software or module is in development. Once the feature development is completed successfully, the feature branch is merged back to the develop branch to add the new feature in the upcoming release. In case of feature development failure or an unsuccessful attempt of the new feature, the branch may be discarded without merging back into develop branch.
• Hotfix Branch: A hotfix branch is branched off from the corresponding tag on the master branch that marks the latest production version. It arises from the necessity to act immediately upon an undesired state of a live production version, for e.g., when there is a bug in the production, or any other issue which needs immediate attention and cannot be waited until the next release.

1.2 Software Development Methodologies

A Branching Model will differ based on the software development methodology used by the project.

The Software Development Lifecycle (SDLC) is a framework which describes the different phases in a software development project. It consists of several phases and each phase has distinct activities, functions and responsibilities. SDLC is a framework for planning, creating, testing and deploying a software application or a product.

The SDLC phases in any project begin after the project is initiated or planned and end once the software or product is deployed into production or handed over to the customer/clients. The work completed in each phase produces results as artefacts that are used as inputs to the later phases.

Different software models implement tasks differently, like

• Waterfall model
• V-Model
• Agile model

1.3 Waterfall Model

The Waterfall modelis a sequential approach model where the phases of Software Development Lifecycle (SDLC) are executed in a linear approach; i.e., the project can be in only one SDLC phase at a time. The current phase work is completed, reviewed and approved, and then the project can move to the next phase. And a phase once completed cannot be revisited. This type of model is a good fit when the requirements and the technology in a project are well understood, and the product definition is stable.

A Branching Model of a project following the Waterfall Methodology will have a sequential approach to its workflow with respect to branch creation/deletion and merging. For e.g., new branches may be created only when a previous branch is closed after a release has gone into production.

1.4 Agile Model

The iterative approach model follows incremental development, iterating to the SDLC multiple times during a project. Agile software models display iterative adaptive characteristics which make them very lightweight. Agile models are less rigid than sequential approaches as they have reduced documentation and can allow for rapid changes that may be inherent in a product’s lifecycle.

During each iteration, a functionality of the software is enhanced and the resulting application is demonstrated to the client/customer. The client/customer then provide their feedback which is incorporated in the system's requirements and the software is enhanced and developed accordingly. These iterations continue with the evolving versions until the full software application is developed which meets all the requirements.

Common agile practices include:

• TDD (Test Driven Development)
• User Stories (“As who, I want what and why?”)
• XP (Extreme programming)
• Scrum approach (consisting of Sprints)

A Branching Model of a project following the Agile Methodology will have an iterative approach to its workflow with respect to branch creation/deletion and merging. For e.g., parallel branches may be created for different releases in an Agile model.

1.5 Branching & Merging Model Timeline - Waterfall vs. Agile

Let us now see a Timeline Model which demonstrates how Waterfall and Agile Models differ in term of merge flow with respect to time. The small iconic “C” symbols represents the number of commits performed on the branches, “M” represents the merged code, while “R” represents a Released product or code. As shown below, Waterfall branching model takes a linear flow wherein new branches are cut-off only when the previous release has been completed, while Agile branching model works on parallel releases.

1.6 The Fortune in Your Ferrari– DevOps in Branching Model

A DevOps branch can be used as a bonus point in any SCM Branching Model. It is not mandatory to have a DevOps branch in a Branching Model. However, to have a placeholder in SCM for DevOps data can have several benefits some of which have been discussed in here.The DevOps branch can be created and kept segregated from other branches which have the code base. This branch will be responsible for storing the automated Build and Deploy scripts, several design and testing documents, release notes with the artifact and build version details, etc.

If the project consists of one or more applications which require several repositories to be maintained for the code, the automated build and deploy scripts might be specific to the application. In that case, a DevOps repository can be created and maintained to store the automation scripts of several applications.

1.7 DevOps Structure

DevOps branch or repository may have the directory structure as shown in the diagram below depending upon the project. The below diagram represents what kind of data can be stored in such a branch/repository and how does it benefit a software development project.

• Environment: The Environment directory may contain the environment specific deployment or test scripts. Deployment scripts usually consists of tasks that push code source control to a non-development tier, or all the steps to move the code from development to production environment. The deployment tasks may include creating databases, modifying any environment specific configuration files, provisioning servers or other administration tasks.
• Testing Environments: The purpose of the test environment is to provide a facility for human testers to manually test the new changed code or to run automated tests on the code. Different types of testing are usually carried out in different types of test environments. Automated scripts related to different test environments can be stored in their respective directories in DevOps branch.
• DEV: A development environment is usually the programmer's workstation where the changed to software are developed or the code is programmed and tested. Development environment may include development tools like a compiler, integrated development environment, different libraries or support software etc. which will not be present in a production or end user's environment. Unit Testing is usually performed at Development environment where which individual units of source code, usage and operating procedures are tested. A unit can be called as the smallest testable part of an application. Scripts related to Unit Testing can be stored here.
• CIT: Component integration testing is the kind of testing where data flow between two or more components are tested. It usually occurs after unit testing and before validation testing.
• SIT: System Integration Testing is performed to test the overall functionality of a complete system which is comprised of many subsystem components. Here the data flow between two or more systems are tested to verify and validate that the system meets its requirements and performs in accordance with end user's expectations.
• UAT: User Acceptance Testing is conducted to verify that the software will work for the end user. It is passed when SME (Subject Matter Expert), who can be client, accepts the solution. UAT can act as a final verification of the required business functionality and proper functioning of the system before it is released to live production environment.
• PROD: The production environment is the live environment that end-users or customers/clients directly interact with. Deploying a code to production means releasing the product to live servers.
• Design docs: This directory may comprise of the design documents specifying use of design pattern, code or design guidelines, User Interface standards, reports, Requirement Traceability Matrix documents, scope documents defining the high-level outlining of the scope of the project, functional specification documents detailing the functional requirements on a business level, detailed technical design documents, user guide documents etc. which are prepared throughout SDLC phases.
• Build: This directory can comprise of build automation scripts having the process of automating the creation of a software build defined. The build scripts can include processes for compiling computer source code into binary code, packaging binary code and generating build artifacts.
• Release Notes: This directory can comprise of Release Notes prepared for every major or minor release. These are the documents which contains all information about the new enhancements or the known issues of the final build that went into production as the latest release; it may also have the process of user guide and training materials. These can be prepared by technical writers or Quality Assurance teams and stored here.
• Infrastructure Management: There are many DevOps tools which also help setup Infrastructure As Code. This means, all steps required to setup an infrastructure can be automated via Infrastructure Automation tools and they can be reused on multiple servers at one time. Few popular known tools are Ansible, Chef, Puppet. Such kind of infrastructure management needs to have scripts written, which can be also be version controlled and tagged for its stable and tested versions. Thus, there can be placeholder in DevOps branch or repository for Infrastructure Management code too.
• Framework Management:Frameworks are used by developers which helps provide them with a conceptual platform to reuse a well-defined application programming interface (API). Developers may redefine or override the common code with generic functionality, or may extend the framework’s functionality. A placeholder in DevOps branch can help store and track versions of Framework management code.

1.8 Branching and Merging Models forProminent SCM Tools

There are many version control tools available in the market. Let us try to list a few popular tools and the branching and merging models for the same.

1.81. GitFlow based Branching Model

1.8.2 Mercurial based Branching Model

1.8.3 ClearCase based Branching Model

ClearCase has a variety of strategies that are tailored to their development environment. ClearCase provides the building blocks to build a successful branching environment. branching strategy will encompass not just creating branch types but also effective use of other ClearCase metadata (labels, attributes, triggers, etc.), view creation/administration/maintenance, configuration specifications, naming conventions, and an underlying policy or process to follow.

• Incremental version history for each file.
• Every file has a different history.
• Every version has a predecessor.
• Branching and merging between baselines.
• The version 0 on a branch has the same contents as version at branch point. Version 0 on the main branch is defined to be empty.
• Regardless of the approach to branching it’s good to merge early and often.
• Branches where changes are eventually gathered helps facilitate the integration and release of software code.

1.8.4 Team Foundation Server (TFS) based Branching Model

• Scenario 1 – No Branches: Your team works only from the main source tree. In this case, you do not create branches and you do not need isolation. This scenario is generally for small or medium size teams that do not require isolation for teams or for features, and do not need the isolation for releases.
• Scenario 2 – Branch for Release: Your team creates branches to support an ongoing release. This is the next most common case where you need to create a branch to stabilize for a release. In this case, your team creates a branch before release time to stabilize the release and then merges changes from the release branch back into the main source tree after the software is released.
• Scenario 3 – Branch for Maintenance: Your team creates a branch to maintain an old build. In this case, you create a branch for your maintenance efforts, so that you do not destabilize your current production builds. You may or may not merge changes from the maintenance branch back into the main tree. For example, you might work on a quick fix for a subset of customers that you do not want to include in the main build.
• Scenario 4 – Branch for Feature: Your team creates branches based on features. In this case, you create a development branch, perform work in the development branch, and then merge back into your main source tree. You can create separate branches for work on specific features to be completed in parallel.
• Scenario 5 – Branch for Team: You branch to isolate sub-teams so they can work without being subject to breaking changes, or can work in parallel towards unique milestones.

1.8.5 Subversion based Branching Model

1.8.6 CVS/PVCS based Branching Model

Concurrent Versions System (CVS) permits to create branches from other branches. Root branch will be treated as a trunk and manage the sub-branches using any of the branch styles depicted below. Nested branches are most useful when using CVS for configuration management. Branching policies helps in ensuring branching of the projects by using consistent rules Having and using consistent policies can also help you keep merging as simple as possible.

• Develop policies that work for your projects and your team.
• Have an overall design of the project.
• Ensure each branch has a purpose.
• Minimize the number of active branches.
• CVS permits nested branches, but there are few situations where multiple layers of nesting help a project.
• Consistent branch-naming scheme that expresses the purpose of each branch.
• Tag the branch at every merge point.
• Tag the trunk at every branch point and just before and after every merge.
• Use consistent tag-naming schemes for the tags associated with the branches.

1.9 Trunk Based Branching Model

Trunk Based Development, also known as TBD, is a source code control mechanism where the single main branch "trunk" is used by the developers to work upon instead of using any other long-lived branches. Any other Release branches created from Trunk are usually short-lived, while the Trunk is the only long-lived branch. Developers are bound to make multiple commits in a day to trunk which helps avoiding merge hells or breaking builds. This in turn satisfies the core requirement of Continuous Integration Where several commits to trunk are performed every day.The code does not break a lot and is always releasable on demand which helps boost Continuous Delivery, thus making TBD a key enabler of CI/CD.

Thus, below points denote a typical TBD workflow:

• Commits to master at least once per day
• Remote branches are only for releases
• Local branches are used by developers
• Hotfixes are also committed to master
• Hotfixes are cherry picked into supported releases

As per the survey data and graphical representations available over the internet, it has been observed that the concept of Release and Development branches were the most popular during the period of 1998 – 2005, however it reduced later as it required high maintenance for the long-lived Release/Development branches. The short-lived branches gained popularity with time. However, Trunk Based Development has been found to be the most stable form of development over the years, and it works well with short-lived Release Branches.

Based on the workflow of TBD, following points summarize its advantages over other branching models:

• Trunk Based Developments are lean in nature. Teams can communicate often and effectively to streamline development
• Release at any time
• Smaller merge problems
• Merge problems evolve early
• Release branches are cheap
• May be no need for geographically distributed development
• Feature toggling and decision routing is used for feature development and deployment

As the complexity of a project/application increases, creating too many branches and maintaining the complexity of branching and merging strategy can be cumbersome and prone to more errors. The future of any project strategy should be to keep minimal branching vs. zero/no branching. Trunk based development is the ideal branching method which helps in avoiding “merge hell”. The code does not break a lot and is always releasable on demand which helps boost Continuous Delivery.

While using TBD branching pattern it is advisable to use peer code review tools or a pull strategy vs. push to ensure code quality and reduce the chances of bad code being introduced into trunk. While Continuous Integration – Automated Code Analysis and Unit testing phases helps ensure high quality of code, peer code review is another shift left technique and tools like Gerrit for automated peer code review.

Sunil Khatri

Add comment