Introduction

When thinking about launching a software project, we need to keep in mind that some different environments are needed so that we can continue developing and testing the software without impacting the user during use. Therefore, it is necessary to manage the release of versions.

Release Management

Release management is one of the main processes in the development of an application, which guarantees its health. This process specifies all steps in the development of a feature (or fix) of the software, from requests to release. The main steps of the construction of a resource are the phases of testing, approval and release to production.

The release management process can be summarized in 6 steps: Planning, building, quality testing, user acceptance testing, release and post-launch.

• Planning: stage in which will be defined what and how will be built;
• Building: development of what was planned, which may be new features, bug-fixing or improvements;
• Quality testing: conducting tests by the internal team to verify that all scope requirements were developed with quality;
• User acceptance testing: the product is released to end users to validate and provide feedback to the team;
• Release: the software is prepared and released to all users;
• Post-launch: a equipe de suporte está de plantão para quaisquer problemas, dúvidas ou bugs que surgirem.

Git Flow

Git Flow is a set of processes developed and published by Vincent Driessen in 2010, which is responsible for defining the branching structure and software release flow (deployment) for projects with a delivery schedule. This framework is based on two main branches: main (formerly called master) and develop.

To understand what Git Flow is, let's first briefly capture what Git is. Git is the world's most widely used versioning system, developed by Linus Torvalds — the famous creator of the Linux operating system kernel — in 2005, and which allows multiple people to work on the same set of files (repository) at the same time. For this, secondary branches of the main code are used so that each member of the development team performs their tasks and, in the end, they are merged into one of the main branches.

Now that we understand what Git is, let's move on to what Git Flow is and how it works. Main is the branch that reflects the production state of the application, the one on which the users are based.

Develop is the branch responsible for new features and software improvements that will be tested and delivered in the next release.

In addition to these, we have some secondary branches of feature, release and hotfix, which have variations according to what is being developed, for example, "feature-billing-report" that would be used for the development of a new feature - billing report.

Applying Release Management with GitFlow

Based on these concepts, we at 80 Lines define our own development and release flow for the software we develop. It is based on four main environments (branches): development, QA (release), staging and production (main), and three secondary branches: New features (feature), development bugs (bugfix) and fixes in production (hotfix), which have variation such as "hotfix/button-click", used to fix a problem when clicking on a button (which was caught in the production environment). So we created what we call a "development belt".

Development environment

This is the first environment, where the tasks planned for the current sprint (time scope with pre-defined tasks following the SCRUM project management model), are developed in feature branches, created from the development branch, which are merged back into the development branch upon completion of development.

Test environment (release)

After the sprint developments are finished, the entire development branch is merged into the release branch, so that our QA - Quality Assurance team can test new features ensuring that all of them meet all requirements with quality. This testing period lasts the same time it took to develop the tasks, in this case, the time determined by the sprint. If a quality problem (bug) is reported to the development team, a bugfix branch is created from the release branch to then fix this problem, re-merge the release branch, and be re-tested by the QA team.

Staging environment

At the end of the testing period, and all issues have been resolved, the release branch is then merged with the staging branch — where there will also be the time period according to the sprint to perform the user acceptance tests, where the software is delivered to end users (usually project stakeholders) to ensure that features have been developed according to expectations. If there are any issues or details to be fixed in this period, hotfix branches are created from the staging branch so that the problem is fixed and then merged back into the staging branch.

Production environment (main)

The last stage of this "belt" is to merge the staging branch into the main branch, which will be officially released to all users. However, in this last step, problems that were not previously foreseen may also occur. In this scenario, hotfix branches are also created, but this time from the main branch and, after the problem is fixed, the branch is merged back into the main branch, completely ending the development flow.

A problem and the solution

After some time using this development flow, we realized that when merging the secondary branches, only in the related primary branches, sync problems between the main branches can happen. For example, if we fix a problem in the staging environment, and in this same place in the code an improvement was developed, or an addition of a feature in the development environment, it is very likely that when performing the movements of the development belt, code conflicts happen or, even worse, a fix or feature is lost without the release manager realizing it.

Therefore, to mitigate this problem, we defined that in addition to creating branches from their related main branch, they must also create from the related branches previous to the environment in question with the same fix to be merged. For example, if an issue is fixed for the staging environment, it is necessary to create three other hotfix branches, one from development, one from release and one from staging, to be merged as well respectively.

Conclusion

Although the concepts of Release Management and GitFlow are not linked to each other, finding a way to use them together was fundamental for us to have a good progress of our projects. In this way, the technical team is always in sync and there is alignment between the planning and business team, providing us a high speed of software delivery.

References

https://www.microfocus.com/en-us/what-is/release-management

https://www.servicenow.com.br/products/itsm/what-is-release-management.html

https://nvie.com/posts/a-successful-git-branching-model/