Branches organization on PDVend Android team

As I said in the last article, not all of our problems have been solved using GitHub + ZenHub to improve the development/QA process of the Android team. And as I promised, in this article I’ll talk about the problems we were facing with the organization of branches of the Android repository and the solution adopted by the team.

The existing branch organization on PDVend’s Android team worked like most organizations: separate branches for new features, improvements and bug fixes that are merge in a development branch and go to master branch when they should go to production.

With this structure everything went very well until starting the famous Quality Assurance on the Android team. With the start of the QA activity any functionality, improvement or bugfix implemented by the development team would be tested by QA. In this context, some problems began to emerge:

• Since we did not have well-defined deliverables (perhaps a subject for another article), when a new version was demanded it was difficult to leave the development branch stable enough to merge into the master and rise to production. This happened because everything that was developed (branch code of new features, improvements or bugfixes) was mergeed in development branch to be tested;
• On the other hand, testing functionalities, enhancements, and fixes on separate branches without merging them into development was not a good alternative, since when talking about testing an android application it would be necessary to generate and install a new version of the application for test each branch, which would require a lot of time.
• Sometimes, to leave the development branch stable it was necessary to ask the development team not to merge in development branch until the new version is uploaded. But if anyone forgot, bye bye stable version.

When we began to address these problems in order to find a solution, we were focused on looking at which branch QA was being done, but, after some reflections on a possible solution, we realized that the problem was not caused by the branch which was being tested, but in fact, by the branch that gave rise to the new release. If all tested code were merged into a branch whose function is to have a stable code, the problem would be solved.

From this perspective, we created the following branch organization in the android team.

• Master branch: branch that has a stable source code and corresponds to the source code of the production app. In the master branch are created tags, which indicate the versions of the app available to users. You can not commit directly to the master branch, instead, you must perform merges of releases or hotfix branches.
• Develop branch: the develop branch originates the branch qa, features branches, bugfixes branches and the release branches, so it must contain a stable code. For this purpose, commits should not be made directly in this branch, only merges of the stable code coming from branch QA.
• Release branch: release branches are created from the develop branch , they must be merged into the master branch and must follow the release/X.X.X standard (depending on the app version). When merged into the master, a tag with the release standard vX.X.X must be created. Realease branches are created for organization purposes, making them easier to view the code of a particular version of the app, making it easier to identify and fix bugs.
• Qa branch: qa branch is created from the develop branch and corresponds to the code that is being developed for the next release and is ready to go through the QA phase. In the qa branch should not be done commits, only merged branches of features or of bugfix. When the QA branch is stable (when all of the code has been approved by QA), it is merged into the develop branch.
• Hotfix branches: Hotfix branches are created for bug fixes that have come up in production. They must be created from the master branch and must be merged again in the master and also in develop and in qa, so that the correction is also in the code that is being developed. The hotfix branches follows the format: hotfix/hotfix_name.
• Features branches: the features branches are used to develop new features, following the pattern feature/function_name. They must be created from development branch and merge in qa branch.
• Bugfixes Branches: are branches created for bug fixes with the default fix/fix_name. Bugfixes branches must be created from development branch and merged in qa branch.

In this new branch structure, the QA of the Android team decides which branches could be merged in the qa branch to be tested. It is also the responsibility of QA to evaluate when the qa branch is stable enough to be merged into branch development and generate a new release, (without risking an unexpected merge that delays delivery of a new release).

With this branching organization the PDVend android team improved the app’s development/QA process and started to make more and more frequent deliveries and ever more stable versions of the app. However, (again) not all our problems have been solved with this structure, in the next article we will talk about the server organization adopted in PDVend.