Home Development GitFlow Or WorkFlow – A Practical Guide To Develop

GitFlow Or WorkFlow – A Practical Guide To Develop

992

You have to build a development workflow to have control over the quality and quantity of each release. The quality refers to the state of bug-free or feature set in each release. And, quantity refers to the frequency of release that you want to have. A development workflow (a.k.a., a gitflow) is a sequence of development steps to release software. In this article, first, I describe the 4 main steps of a gitflow including code change, test, build, and deploy. Then, I describe the 2 most important development workflows that are essentials for startup companies.

Related Link- Gitflow Workflow – Atlassian

What are 4 Main Steps of a GitFlow?

1- Develop

You must make any change (develop a feature or fix a bug) to the codebase in an isolated branch taken from the source branch. Then, you must submit the code change as a pull-request to merge into the source branch. The pull-request will wait for the code review and the results of the automated developer-level tests. If the code changes receive the required approval, it will be merged into the source branch. 

Related Link- Making a Pull Request

2- Test

You must test a software product using automated tests and user acceptance tests (UAT). The automated test has 2 types, i.e., developer-level tests (e.g., unit and integration) and user-level tests (e.g., acceptance and performance). Developer-level tests evaluate the code and user-level tests evaluate the total solution. You can execute automated tests by a continuous integration service such as CircleCI or TeamCity. And, UATs are executed by the quality assurance (QA) team or a product manager. The practice of integration and validation of the codebase at each commit by running an automated process is called Continuous Integration.

Related Link- Setting up continuous integration with GitHub

Which one you think is more important? 1. Developer-level tests 2. User-level tests Click To Tweet

3- Build

You must build a binary solution such as a Docker image before deploying a service on the cloud. Then, you must store binary solutions on a binary repository manager such as JFrog or DockerHub. It is important to tag binary solutions properly since you always need to retrieve them later. For example, you can tag solutions using commit id since it shows where the solution is built upon. The practice of building and storing a binary solution from each commit is called Continuous Delivery.

4- Deploy

You must use an orchestrator such as Mesos DC/OS or Kubernetes to run and orchestrate microservices on cloud (a.k.a., deploy). A microservice is an all-in-one software solution that solely executes a process. In Docker technology stack, binary solutions are Docker images and deployed solutions are Docker containers. The orchestrator in the Docker technology stack is Docker Swarm. Note that you must thoroughly specify the deployment configuration details in this step. The practice of deploying a solution is called Continuous Deployment.

What are 2 Most Common GitFlows?

If you need a fast development process with a frequent release, you have to select a gitflow or workflow without a gatekeeper. It is hard to keep the sanity of the final product in this gitflow. If you have a large number of users, you have to care more about the quality. So, you have to put a gatekeeper in the development process to check the quality. The high-quality software comes with the cost of low-frequency release.

A GitFlow Without Gatekeeper (High-Frequency and Low-Quality)

In this gitflow, as seen in Figure 1, any code change directly merges to the master branch if it (a) passes developer-level tests and (b) receives the required merge approval. Plus, the deployment process starts right after a new commit gets merged into the master branch. Therefore, commits may introduce new bugs to the solution at each time.

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

On the other hand, you can not delay the development process for any reason. Plus, this gitflow can not even have a gatekeeper (e.g., a product manager) in place to sign off the release. Therefore, bugs slip through the automated tests and ship to customers anyway. You must fix those bugs as soon as the company receives feedback from its customers. In this gitflow, we only have a development environment (attached to the master branch) and a cloud infrastructure.

Figure 1- Without a gatekeeper

Related Link- ENV Branching with Git

A GitFlow With Gatekeeper (Low-Frequency and High-Quality)

In this gitflow, you must develop features on the master branch and fix bugs on the release branch. The release branch creates an isolated environment for product managers to have more control over the feature development and release quality. In most companies, a product manager with a QA team is in charge of testing the product and reporting bugs. Nevertheless, it is not possible to have 100% test coverage. So, bugs may slip through the test process. In this gitflow, we have 2 development environments including development (attached to the master branch) and release (attached to the release branch) and 2 cloud clusters (Figure 2).

Figure 2- With a gatekeeper

Takeaway

You have to build an efficient development workflow or gitflow in each stage of development based on the quality and quantity of the required release. Note that high-quality software comes with the cost of low-frequency release.

Subscribe for insightful articles and expert tips

Advertisements

Leave a Reply