Enterprise Boozang: Branching and merging

This article explains how to use branch and merge functionality in Boozang, and how to align your test automation work in a software project running on several branches at once.

Boozang is Cloud-based and uses it’s own servers to store the test automation scripts that is created. Just like developers might use a versioning system to branch and merge their code, Boozang also supports branching and merging, allowing you to align the automation code with the software updates, maintaining the same ways-of-working for automation and code.

In this example we show how you can branch your automation code for a patch, and follow up with an example which is more close to a real-life scenario.

Disclaimer: This functionality is still in Beta.

Branching and merging of code

When running small scale software projects, it’s often ok to work in a single branch of code. As the team scales up, it’s helpful to work on different branches. The simplest example of this is when a software branch is needed to deliver a patch for a specific bug-fix.

In Git, a branch can be created easily using the checkout command

git checkout -b patch_tr456

The developer works on the “patch_tr456” branch and keeps making commits until it’s ready to be merged. When it’s finally time to be included in the original branch, the code needs to be merged back

git checkout master
git merge patch_tr456

As you can see, the acton of merging is done from the branch which is being updated. One can say we are “merging ‘patch_tr456’ into master”.

There is a good reason for this. If someone has updated the “master” branch in a way that conflicts with the change in “patch_tr456” (meaning the same files was updated in the same place) we will have a conflict.

This conflict will be resolved in the “master” branch before pushing the final update to the “master” branch.

Branching and merging in Boozang

For automation code, it’s often not needed to create branches for individual bug fixes. It’s often better to let tests fail, and wait for bug fixes to be delivered without “green-lighting” any potential bugs.

On the other hand, where you have bigger fixes, it can still be interesting to branch the automation code to support regressions for a newly introduced bug.

Creating a branch in Boozang

In Boozang start by creating a separate branch for your patch release using the branch functionality in Boozang

Working in the branch

After you have created a separate branch, the branches will show up in the dropdown in the root of the navigator.

As long as you make sure you are in the right branch, you can work securely without impacting the other branches. Complete the work in a branch, until you are ready to merge it into to your main working branch (usually “master”).

Merging in Boozang

In order to merge back the change, make sure you are in the branch you want to update (compare with Git). This means, in order to get the “patch_456” back into the “master” branch, make sure you are on the “master” branch when merging.

As soon as you select the branch to merge from, you will see all the changes being displayed.

Usually, using the default settings is fine. If you want to “cherry-pick” changes, or if there is a need for a manual merge, that is also supported

Usually it’s recommended to keep this process simple. If you aren’t sure of a change, keep the version in the “master” branch. You can always run the merge a second time if you need to merge in more changes from the “patch_456” branch.

Aligning with the SW process

Normally, there is no need to branch the automation code for individual bug fixes. If you have a larger code release, it can be a big time-saver to branch the automation code. That way you don’t have to spend too much time catching up with the new release. It can also be great when re-factoring the automation code.

Imagine the following typical scenario. The code being developed is maintained in 3 different branches

• master – the master branch
• ver40 – an upcoming (disruptive) version of the product
• release – branch used to make product releases

A typical workflow

The master branch is being used for the normal work-flow, adding bug fixes and minor code updates on a daily basis. The “ver40” branch represent a future release, and is actually “ahead” of master. The release branch is “behind” master and is used to create stable releases into production.

This setup is fairly typical, and it’s not uncommon that different parts of the development team are working on different branches. Maybe half the team are working on master branch, and half the team is working on the “ver40” branch.

Test automation challenges

The challenge in test automation would be to allow for the creation of new tests for “ver40” features, without breaking any of the existing tests. In Boozang, the easiest way to handle this is simply to replicate the exact branches on the Boozang side.

Testing activities

Simply use the “master” test branch for maintaining tests for “master”, “ver40” for tests on “ver40”, and the “release” branch for the release. This probably means that all your CI jobs are being run from the “release” branch.

Imagine the follow regular release at the end of a Sprint

• Code “master” merges into “release”
• Test “master” merges into “release” to prepare for CI runs
• Release is deployed into staging
• CI runs regression tests on code (on “release”)
• Release is deployed into production

Now, imagine a larger release when “ver40” needs to be deployed.

• Code “dev40” merges into “release”
• Test “dev40” merges into “release” to prepare for CI runs
• Release is deployed into staging
• CI runs regression tests on code (on “release”)
• Release is deployed into production

Benefits and drawbacks

As you can see, you can maintain the same ways of working in these two cases. There are some benefits with this approach

• No big lag time to build test automation for “dev40” features.
• Less dramatic release event

There are also some drawbacks

• Need bandwidth to work on several test automation branches at once

In the end, you decide what works for your team.

Summary

Always aligning the source code life-cycle with automation code will probably create more overhead than desirable. Usually, it’s better to try and keep the automation code fairly monolithic, making sure tests fail if certain bug-fixes aren’t delivered.

On the other hand, when dealing with large bug-fixes or releases, it’s better to branch off the automation code, making sure the main pipeline is working. By branching off the automation code, you can be prepared for whenever the larger fix is merged for deployment into production, and be less reactive when it comes to these bigger release events.