Automation of Branching, Merging, and Notifications in Parallel Development

In my last article, I highlighted the importance of automation in an agile environment. Automating the version control system (VCS) operations normally performed by developers is an achievable and worthwhile first step.

The VCS acts as a repository for source code and software that maintains the files along with history. Whether using a centralized or distributed version control system, the platform provided by the VCS should supply information a developer or release manager can use to revert to a stable commit or revision, because any modification to a particular file can be tracked by its history. Configuring an environment requires taking advantage of the numerous tools (such as hooks) for automation that exist in the VCS.

Developer Pain Points

Software developers primarily focus on writing source code to build software programs. However, they are often distracted from their core function by challenges with their VCS usage, such as creating a branch to start the development, standardizing naming conventions, and determining which codeline needs to be branched. Furthermore, after development, developers are required to send code for review, merge or demerge the code, and update working repositories. These tasks look small because they are distributed throughout the development process and can pop up at any point in the lifecycle. However, they take precious developer time and leave staff frustrated, especially if problems arise.

While teams already have some version control systems with GUI models, the interface doesn't address developer needs because they are just visual abstractions of the command line approach into a visual scheme that doesn’t really help improve ease of use.

Many teams use issue tracking and workflow automation tools to track the steps in the development process. Within each step, the status of the issues helps to track the stage of the development process and is sometimes integrated with version control systems to provide traceability in what has become known as task-based development. The branching model plays an important role in the release of software from the developer's point of view. Usually, regardless of what the branching model is, the naming conventions should be specified and communicated to the development teams.

Beyond communicating and educating teams on naming conventions for a project, enforcing these conventions with developers can be difficult. Remember, all the VCS activities are performed by the individual developers themselves. Whether due to stubbornness or error, developers will often not adhere to naming conventions. This can land them in trouble, such as while branching (determining the branch name or the parent branch that has to be branched out) or merging after development (determining with which branch they need to merge, getting their branch reviewed, and conflicts due to parallel development of other developers). Consequently, it is generally recognized as a best practice to never give developers administrative permissions to create branches or merge directly to any branch (e.g., production) that can result in errors that could break the repository.

In order to overcome these challenges, reduce error, and increase participation, these steps must be automated and abstracted from the developers. It is a good idea to assign the administrative role to a select development lead or an engineer performing the release engineering role, control commits to the production branch, or automate this process using gated check-ins.

Auto-Branching

Every organization should have a branching strategy for every project and release. Typical strategies are often executed by release management teams and center around those teams performing necessary operations using version control systems. However, when releases are tracked on issue-tracking systems, integration with version control systems enables the teams to turn on automation for their development process.

The best practice is to base the automatic creation of a branch on communication with the VCS in which the branching model and naming conventions being followed are based on corresponding events in the issue-tracking system. This removes the details of VCS activities from the developer. By modeling branching models and related details in an issue-tracking system, the commit can be pushed to the central repository automatically once the developer triggers the resolution event on an issue. The same branch can then be built and deployed to the specified environment by using continuous integration tools, which employ automated procedures as well. The status of the build is then auto-updated on the issue ticket, and the reviewer is notified to approve or reject changes.

A prerequisite for implementation of an auto-branching strategy is that every issue in the issue-tracking system must have a corresponding branch in the VCS. For example, a release ticket would have a release branch, a feature ticket would have a feature branch, and so on, all of which subscribe to the set branching model. This automation can thus be independent of the nomenclature and branching model followed across the organization, as aligned to existing organizational practices.

The best approach is to model the VCS repository or project, branching model, and branching nomenclature details in the issue-tracking system and use them to administer the automation of the VCS. If the VCS is not automated and integrated with the issue-tracking system and continuous integration tool, the branch for the developer and related activities needs to be manually managed by a developer or a VCS admin.

After the code is pushed to the VCS, the corresponding build for every change has to be triggered manually. Unfortunately, this represents an ever-increasing overhead to whoever is managing the VCS and the continuous integration tool. As such, code reviewing becomes cumbersome, as the build results are not readily available on the VCS. Consequently, VCS integration to the issue-tracking system and the VCS tool does not just represent an advanced feature, but in fact a necessity for any growing organization.

Auto-Merging and Notification on Parallel Development

Code and branch merges are done with different contexts as per organizational needs. Because merging is recommended only when the branch is deployed and tested successfully, branches should be merged with their parent branch(es) as specified by the branching model. This can be automated with passing of the “test” in the issue-tracking system for the issue, which removes the overhead from developers. In case of code conflicts, the developers should be notified on the issue ticket.

Developers usually need to update their working copy in order to lower the possibility of conflicts at the merging level because there is often parallel development going on for a release. It's necessary that the developers are notified regarding any changes made to the parent branch on which they are working so that they can update their local repository with the same changes. This notification from the VCS should be automated and distributed to the developers listed on the issue. Otherwise, there would be no notifications about the changes on the repository to the developers, which means local repositories never would be updated until the developers encounter the conflict during the code push or code merge. When complex merge conflicts occur, developers can waste significant time resolving them.

Branching and merging strategies should always go hand in hand. If the branching model is a top-down (release branch > developer branch) approach, then merging needs to be down-top (developer branch > release branch). Because the speed of development directly reflects the release pace, taking the burden of performing manual VCS operations off the developers makes a release process shine. Considering the VCS has a major role in the release, its automation mitigates the chances of manual error, especially when integration of the VCS with the issue-tracking system and its automation is also integrated with the continuous integration tool for auto-build and deployment.

Conclusion

In my opinion, automation should really be called integration. By maintaining strategic focus, organizations can take the time to ensure their tools are working hard enough to justify their cost. Part of that equation is making sure they are working together.