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- Code Change
You must do a code change (develop a feature or fix a bug) in a git 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, you merge it into the source branch.
Related Link- Making a Pull Request
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 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 validating the codebase at each commit by running automated tests is called Continuous Integration.
Related Link- Setting up continuous integration with GitHubWhich one you think is more important? 1. Developer-level tests 2. User-level tests Click To Tweet
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.
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.
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).
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.