Which git workflow model did we choose in the Blupoint CMS project?
As we know, it is inevitable to use a version control system when developing software. Git is one of the most popular version control system implementations. We used the Git when developing the Blupoint CMS project and kept our codes on the bitbucket repositories. Depending on the size of the project, different git flows may be preferred. ( Centralized Workflow, Feature Branching Workflow, Gitflow, Forking Workflow etc.)Blupoint CMS team chose Feature Branching Workflow. In this post, I will try to explain the main reasons why we prefer feature branching wokflow, which we don’t prefer other workflows, what problems we have encountered when implementing these workflows in the team and what advantages it provides us.
First of all, I would like to give a brief information about the project. The Blupoint CMS project began to be written as a modern and generic version of CMS products previously developed under the same company. The base of the project was modeled by people who are experienced in the media sector and content delivery, and rearranged according to competitor analysis and user feedbacks. It is used by Turkey’s leading media companies (BluTv, Posta, Fanatik, NetD, KanalD International), and with a much wider range of features than the leading CMS products in the world. It is also on the way to becoming SaaS. You can visit the website for detailed information about the project.
Project development team; 2 backend developers, 2 frontend developers, 1 project manager, 1 data scientist, 1 devops, 1 test specialist and 1 product manager, including a total of 9 people. We can say that there are 5 developers active code writer in the team. As such, we had to avoid potential conflicts when writing code, to make it easier to retrieve the code developed when needed, to quickly resolve any bugs that may arise, and to use a git workflows for other similar scenarios. There were 3 different alternatives. These; Gitflow, Feature branching workflow, forking workflow.
How did we decide?
The answers to some questions were effective when deciding between these options. First of these questions: Is this workflow scaled by team size? So the team is now 9 people and when the team grows, can we use the same workflow model? Will it cause any trouble to us? Second; Is it easy to get errors and errors back with a workflow? Third: Does this workflow bring an unnecessary new cognitive overhead to the team? Here are the answers to these questions.
Scalability
As mentioned above, our team consists of 5 people (only developers). Again, as mentioned above, the number of people who have a lot of customers and which is a project on the way to becoming SaaS, the number of development can increase from 5 to 15, from 15 to 55.This is entirely about the return value of the project. In this case, the workflow model, which offers beautiful solutions for 5 people, will be able to offer the same solutions for 55 people?
So how did we answer the questions as a team?
- Gitflow
First you can follow the link below for detailed information about gitflow.
A pretty ideal workflow model for a 5-person development team. However, it is a hard workflow model that continues to work when the number of developers reaches 55. There is absolutely no luxury to make mistakes in such a this project. This requires a highly defensive deployment setup. We need env’ronments like test environment, development environment, stage environment and production environment. It is very difficult to manage all these environments within the capabilities of Gitflow.
- Feature Branching Workflow
For more information about Feature branching workflow, please follow the link below.
This flow basically tells us that. Each issue to be developed should be made in isolated environments during development. Similarly, bugs or refactors to be solved must be isolated from each other. This means opening a new branch for each issue.
Likewise, it enables deployment environments to be installed and managed. Develop branch for development environment, stage branch for stage environment etc.
In addition, there may be situations in which the features developed should be tested only on the basis of that particular feature. In such cases, the deployment of the branch with only that feature so this allows the dynamic creation of new environments.
Feature Branching Workflow a proper answer to our first question.
- Forking Workflow
If you want to get detailed information about this workflow model, you can follow the link below.
We thought it might be overkill for a team of five. Because managing this workflow will require additional effort. However, our topic is scalability, the answer to our first question is an appropriate workflow model.
Undo Mistakes
Any errors made can be solved in more than one way. Fast retrieval of an error in a code is very important to prevent it from affecting more users. Therefore, we will look for the answer to the question of whether we can easily retrieve the errors made in the work flow model. Can we get the wrong code back at once and with the opportunities offered by the workflow model without developing?
In the meantime, the project deployment should be as defensive as possible for minimum error. It should be deployed in many steps instead of deploying at one time.
- Gitflow
Each feature is developed on a different branch, this may be an appropriate answer to our question. We said we should have more than one application environment. In all these environments, it is difficult to perform the rollback process. We are a bit shaken when giving the answer yes.
- Feature Branching Workflow
This workflow model was an appropriate answer, since both have different branches for each job, provide isolated development environments and can successfully manage the environment.
- Forking Workflow
Rollback is possible in the event of any error in this workflow model. So this work flow model is also an appropriate answer.
Cognitive Overhead
Any workflow model to be selected should not give the team any extra workload. That’s because this road has chosen to make things easier.
- Gitflow
It can be an appropriate answer because there is not a lot of cognitive overhead and a workflow model that people in the team can easily implement.
- Feature Branching Workflow
It may seem more complicated than Gitflow, but it means that each job has a separate environment and can be easily implemented. So this work flow model is an appropriate answer to this question.
- Forking Workflow
Anyone who is a project developer is required to re-create the project in each feature development, hotfix or bugfix situation. (Or they will have to work on their forked (out-of-date) repo.) It will improve the time of problem solving and feature development. At least we can say that in the Blupoint CMS team.
If you look into this workflow model, you can see that the cognitive load is more than other workflow models. So there will not be an appropriate answer to this question.
As a result of our answers to the questions we have obtained the following table.
In addition to all this we can say. In order to develop stable applications, we should make the deployments at the end of a few steps instead of a single step. Before going to live a code must be reviewed by another developer, written tests should be done, then the tests should be deployed in the test environment, then deployed in stage environment and passed the required customer tests and uat. Finally, it can be deploy to production. The first step of all these steps is the code review process, which has an important place in workflow models and the concept that we call pull request is used. It is easy and clear to implement this concept in feature branching workflow.
What are the advantages of our decision?
Because more than one person could work in different environments at the same time, they did not block each other. Both feature development, refactor and bugfix operations were completed quickly. We have been able to produce small units that can be tested with the split and manage approach.
The incorrect code that was developed on any branch and deployed to production was rollbacked in seconds.
The long-breed refactor operations did not affect the planned sprint because of their operations implemented in different branches.
The sharing of responsibility within the team becomes concrete.
What kind of problems did we have?
The pull request and code review cannot be accepted from some developers because it is still slow despite many advantages. In the early days we have encountered this problem. But in a short time we have overcome this. No code can be published without review.
Managing all these flows correctly is a time-consuming task. Managers always want to be published quickly. But we can’t go so fast in this workflow model. It was not difficult for some of our executives to accept this situation. But in addition, there were managers who supported us.
Did we make the right decision?
We have been working with this work flow model for about 2 years. We’re glad we didn’t have a technical load. We can say that the quality of the work has increased noticeably. The responsibility was sharing. The single point of failure with code review and pull requests has been reduced to a minimum. We have stable applications because of we are deploying with multiple steps and deploying in multiple environments.
