The most important elements of a software project are people’s creativity, strategies agreed, and support for tools. The right people need to be involved in automation, strategies need to be discussed and agreed, tools for automation and branching support needs to be chosen. Also, team coordination on how the automation framework should be structured to fulfill the end goal of the organization is important. Today we’re going to focus on one important aspect which is the branching support. We are going to talk about a simple, yet effective git branching automation strategy that will ease the process of testing.
Git Branching Automation Strategy
Basically the rule of GIT branching follows the same steps as any development team does. Imagine having a large scale project where many features are in a queue waiting to be developed and tested. The features are complex and they need to be split into small units. Teams must be divided on who will work the unit 1, unit 2 … unit n. If testers work on the same branch, pushing changes for the features often will destabilize the branching process, and the cost for reverting the changes/ fixing them will be higher.
That’s why the right git branching automation strategy needs to be chosen. My personal favorite is the so-called feature-oriented strategy where we have three branches and all our work should be included there.
Branch structure
The feature-oriented branch strategy is focused on the feature being developed. It is a structure where we have the master branch, develop branch, and our feature branch. The testing team needs to develop an automation test for that feature to cover all functionalities. Let’s look at the branches in detail.
Master branch
This is the master branch where all our production-ready code is stored. This is the place where we are 100% sure that the feature is developed the right way according to the client’s requirements and tested appropriately with automation tests based on the previously created test plan from the develop branch. All changes from that branch are merged in here and the code iteration is shipped to the client. Wo don’t make any changes, even small ones in the master branch, ever!
Develop branch
The develop branch is created from the master branch from the point when we’re starting to develop the feature. This branch will serve us as a “master” branch and we will merge all our changes from the feature branches to this branch. Every change from the developer or testers’ side will be tested in this branch. When we are finished with the development and automation coverage of all scenarios regarding the feature, then we’ll open a pull request that will merge all the changes from the develop branch to the master branch.
We cannot mess up the production code (master branch) so having a so-called release-branch is definitely the right way to go. It is safe, secure, and even if we make a mistake during coding or automating, we can easily revert it, debug it an do the necessary changes.
Feature branch
This is the branch where every tester and developer needs to create and work on. Separate feature branches need to be created for every member that will work on that feature. If multiple testers write tests on the same feature branch, one can have something changed and that will have an impact on others when pulling the latest changes. That’s why it is advised for everyone to create separate branches. Once we create the branch from the develop branch and when we’re done with our automation test coverage, we merge this branch into the develop branch and delete out branch.
Interested to know more about GIT? Become a Git & GitHub expert by mastering concepts like Branches, Design, and Git workflow by using Git Command Line, GitHub Desktop, and SourceTree.
Conclusion
Following the feature-oriented git branching automation strategy will make your automation process very stable and secure and will have a positive impact on the overall test effectiveness as well. You will avoid real hell working in one branch and do all the changes from the developer or testing aspect in one place. It is widely used, it is pretty straight forward, reduces the chances of errors being made late on the project life-cycle, and the cost of resources for any error found is smaller compared to the errors found in the later stage.
Share this post
