Everything starts from the release management. But, what is release management?
The philosophy of development defines release management in a company. The release management strategy has answers to the questions below.
- How frequent you want to release the product?
- How much control do you need on feature release?
- What is the tolerance of having bugs in the product?
In short, you can categorize release management strategies based on the quality of release and quantity of release. To achieve goals in quality and quantity, the development process must follow a specific GitFlow. Regardless of the type, a GitFlow has 4 major components.
- Code Change (Develop Feature or Fix Bug)
- QA Process
- Build Solution
- Deploy Solution
In this article, I describe the 4 components of a GitFlow in nutshell. Then, I explain 2 common GitFlows mostly appropriate for startup companies.
1- Code Change
Code change means any change in the codebase to develop a feature or fix a bug. Code change needs to be done in a separate Git branch took from a source branch. After conducting the development, you must submit the code change as a pull-request to merge into the source branch.
Related Links- Making a pull-request
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. The practice of validating the codebase at each Commit by running automated tests is called Continuous Integration.
Related Link- Setting up continuous integration with GitHubDeveloper-level tests evaluate the code and user-level tests evaluate the solution. Click To Tweet
2- QA Process
The QA process can be split into [a] automated tests and [b] user acceptance tests (UAT). The automated tests can be split into:
- developer-level tests (e.g., unit and integration)
- user-level tests (e.g., acceptance and performance).
Developer-level tests evaluate the code and user-level tests evaluate the solution. The automated tests are executed by a continuous integration service such as CircleCI or TeamCity. The UATs are executed by the QA team or a product manager.
Related Link- The different types of software testing
3- Build Solution
To deploy a service on the cloud, you have to, first, build binary solutions such as Docker images. You must then store the binary solution on a binary repository manager (e.g., JFrog or DockerHub or Amazon ECR).
You need to retrieve binary solutions based on metadata such as model performances or an original Commit ID. So, it is important to tag the binary solution properly such that you can retrieve any required solution if needed. The practice of building and storing a binary solution from each Commit is called Continuous Delivery.You need to retrieve binary solutions based on metadata such as a model performance or an original Commit ID. Click To Tweet
4- Deploy Solution
First, what does “deploy” mean?
In brief, “deploy” means to run and orchestrate several containers each of which built based on all-in-one software packages (e.g., Docker images).
After you build and store binary solutions, you must deploy the solution on the cloud. To deploy a service on the cloud, you will use an orchestrator such as Mesos DC/OS or Kubernetes. These tools help to run and orchestrate Docker containers. Note that you must specify the deployment configuration details in this component. The practice of deploying a solution in the GitFlow is called Continuous Deployment.
In the early stage, a startup company needs a fast product development process with a frequent release. You can achieve this only by having no gatekeeper in the development process.In the early stage, a startup company needs a fast product development process with a frequent release. Click To Tweet
It is hard to keep the sanity of the final product in this GitFlow. But, Why?
As seen in Figure 1, any code change directly merges to the Master branch if it passes developer-level tests and receives the required approval. Plus, the deployment process starts right after the new Commit gets merged into the Master branch. Therefore, Commits may introduce new bugs to the solution at each time.
On the other hand, the development process can not be delayed to keep the solution in order. Plus, this GitFlow can not even have a gatekeeper in place (e.g., a product manager) to sign off the release. Therefore, bugs slip through the automated tests and ship to customers anyway. They must get fixed as soon as the company receives any feedback.
We only have one development environment including the Master branch and a cloud infrastructure.
Related Link- ENV Branching with Git
In this release management strategy, we have a high-quality final product with the cost of low-frequency release.
It is not possible to have 100% automated test coverage. So, bugs will slip through the automated tests regardless of the quality of developers. In most companies, a product manager with a QA team is in charge of testing the product and report bugs.
We have 2 development environments that include the Master and Release branches and two cloud infrastructure (Figure 2).