Git-Flow is the Source of Productivity, Not Confusion

The architecture of the development workflow is designed based on the

quality

and

quantity

of releases. Here, quality refers to the state of bug-free or feature set in each release. And, quantity refers to the number of releases over the course of development. This architecture is not usually that complex; however, it can be a source of confusion.

A development workflow, also known as a git-flow, is a sequence of development steps to build and release software. Git is a popular and powerful version controlling technology that is used in many companies; however, there are other technologies such as Perforce or Mercurial. In this article, I use git-flow instead of development workflow without loss of generality. 

Here, I explain two git-flow architectures that are essential for startups. Knowing the details of these architectures may resolve unnecessary conflicts among development, product, and management teams. In the end, I explain the nuts and bolts of a git-flow that is useful to understand it better.

Note that git-flow architectures can become more complex in comparison to what you can find in this article. Nevertheless, if you learn the details of the two most essential git-flows you will easily understand any complex git-flow when it is needed. 

I. What are the two most common git-flows?

There are various git-flows used in the software industry. However, two of them are commonly used in startup companies. Below, I first describe two scenarios and, then, explain two git-flows applicable in these scenarios.

Scenario 1. You need a fast development process with frequent releases. You do not want to have a gatekeeper to sign off releases. You accept to accidentally introduce minor bugs into the master branch without causing the main functionalities to stop. Plus, you do not need to have control over the feature list in each release. In this case, you must use high-frequency and low-quality architecture. 

Scenario 2. You have a relatively large number of users. You must extensively validate the quality of the product before each release. You want to have a team that constantly reviews the product, and a gatekeeper to sign off releases. In this case, you must use low-frequency and high-quality architecture.

A gatekeeper is a person who reviews the product quality regularly and decides when the product is ready to release. In most startups, product managers are gatekeepers.

— High-Frequency and Low-Quality

In this git-flow, there is only one main source branch where developments are merged into and releases are taken from. 

During the early stages of startups, the development workflow can not be delayed for any reason. There are not paying customers, and the main focus is on the development. So, development teams aim to detect bugs only through automated tests and accept to have some bugs in new releases. Since this git-flow does not have a gatekeeper to sign off releases, bugs simply slip through automated tests to releases. These bugs must be fixed as soon as they are discovered.

— Low-Frequency and High-Quality

In this git-flow, there are two main source branches: master and release. The development team works on the master branch to build the product and works on the release branch to make the product ready for releases. 

The release branch creates an isolated environment for the product manager to have more control over the feature development and release quality. Within the product team, QA engineers run manual tests on the release branch to find and report bugs that must be fixed and merged into the release branch. In the end, the product manager as the gatekeeper is in charge to sign off releases. 

High-quality software comes with the cost of low-frequency release.

It is not possible to have 100% test coverage anyway. So, bugs may slip through the test process in this git-flow as well. However, the quality of releases in this architecture is more reliable than what we can get from the former architecture. 

II. What are the main steps of a git-flow?

— Develop

The first step in a git-flow is a code change, i.e., a feature development or a bug fix. When you want to make a change in the codebase, you must always create an isolated branch to prevent unwanted changes in the source branch. 

After you are done with the development, you must merge the recent change into the source branch through a standard process. Github calls this process pull-request and GitLab calls it merge-request while both refer to the same process. 

In this process, code changes wait for developer-level tests (such as unit, integration, and regression tests) and code reviews. There are some applications such as Hound that also make code review process partially automated. If code changes can pass the tests and receive the required approval, they are merged into the source branch. And, development continues!

— Test

Quality software is all about the balance between test and development. There are two critical points in the git-flow to run a test. First, right before merging code changes into the source branch (e.g., master or release), second, before shipping a product to customers. 

Knowing the importance of software tests, the question is how many types of tests we have. Tests can be automated or manual.

Automated tests

are executed by DevOps solutions such as CircleCI and test frameworks such as PyTest in a completely automated fashion.

Manual tests

are executed by the product team and aim to cover parts that are not tested by automated tests.

Here, I categorize software tests based on the high-level value that they provide to the development workflow. There are 2 different types of tests: developer-level and user-level.

Developer-level tests

such as unit, integration, and regression tests that evaluate the code sanity and is executed after each commit on the git-flow and before the build process. These tests are completely automated. Its goal is to ensure

code sanity

and to

increase the pace of development

.

Developers are the owners of these tests in the workflow. 

User-level tests

such as acceptance and performance tests that evaluate the total solution and are executed after the deployment. These tests are manual and automated. Its goal is to

emulate user experience

and to

measure the quality of service

as a whole. In most startups, product managers are the owners of these tests in the workflow since these tests are mostly user-oriented. 

In most cases, you must significantly rely on automated tests to check sanity and quality. However, it does not mean that manual tests must not be used in the process at all. 

The practice of integration and validation of the codebase at each commit by running an automated process is called

Continuous Integration.

— Build

Build refers to processes where the source code along with its artifacts are compiled and packaged. The output of the build step is a binary file that is ready to deploy on the cloud. 

Example.

When you use Docker to build a binary file, the output of the build process is called Docker image that is a snapshot of the virtual machine environment where it was built.

These binary files must be stored on binary repository managers such as JFrog or DockerHub. When you store them in a repository manager, you must tag them such that they can be easily searched and retrieved, especially when you want to deploy them automatically. For example, you can tag binary files using commit ID, created by git, since it exactly shows where the solution is built upon and it works as a unique identifier.

The practice of building and storing a binary solution from each commit is called

Continuous Delivery

.

— Deploy

Deploy refers to processes where all of the build artifacts collect, execute, and orchestrate on a cloud or a server using an orchestrator such as Mesos, Kubernetes, or Docker Swarm. 

Example.

When you use Docker to deploy a solution, a Docker container is created that can be run on your local machine or on a computing node at a cloud infrastructure such as Amazon EC2. 

The best practice is to specify a cloud environment for each master and release branch. The cloud environments of master and release branches are called development (dev) and production (prod) respectively. In a more complex workflow, there is a staging environment that is beyond the scope of this article.

If you use the microservice architecture, you can deploy each microservice such as frontend, backend, or database independently. The collection of microservices are orchestrated to build the main service. The microservice architecture lets you test, maintain, and deploy loosely-coupled services independently and efficiently. There is no need to say that you need to configure this orchestration properly which is also beyond the scope of this article.

The practice of constantly deploying a solution without any intervention is called

Continuous Deployment.

You can use different git-flow architectures at your startups based on the requirements that you have in the industry, company stage, or customer expectations. In this article, I only describe the most essential parts that everyone must know to have a productive team and to reduce unnecessary conflicts. Kudos 😊