koyoproBackground
In a server-side development project, we were using Git-Flow (or something similar), but we faced difficulties during production releases. This article is about how we changed the Git workflow to solve these issues.
First, I'll explain the problem in order, so if you're only interested in the conclusion (the new workflow), you can skip to this section.
There are several well-known Git workflows, such as Git-Flow, GitHub Flow, and GitLab Flow, but our new workflow felt a bit different from any of these, so I decided to summarize it.
Overview of the Project Where It Was Introduced
The best workflow depends on the project, so I'll briefly describe the project where we introduced this new workflow.
- There are fewer than 10 developers (engineers).
- It's a relatively small team, but larger than just one or two people.
- The contents of the develop branch are always reflected on the testing server.
- Updates to the develop branch are automatically uploaded via CI.
- The contents of the master branch are reflected in the production environment.
- The master branch must always be in a releasable state.
- Feature branches are developed locally.
- Most people develop on their Mac locally.
- There is only one testing server.
- We have considered setting up a server for each branch, but the current operation has determined that one server is more suitable.
- Production releases occur about once every few days to two weeks.
- It's not the kind of environment where we release to production multiple times a day.
- The release process itself is simple, just one command if the updates are in the master branch, so the cost of the process is low.
The Original Workflow
Branch Model
Although we called it Git-Flow, it wasn’t the full Git-Flow but rather a workflow with the release branch omitted.
- develop
- The branch for internal testing.
- feature/xxx
- A local branch for developing features.
- Branched off from develop.
- master
- The branch for production.
In the diagram above, two feature branches are created and reflected on the testing server when merged into develop. After passing the tests for each branch, merge develop into master and release.
Unable to release without other feature tests passing
Here’s a scenario where this flow causes problems.
The same flow as before, but it becomes problematic when you want to release feature/2 immediately after it has passed the tests. This is because feature/1, which requires fixes and testing, gets released together.
You might think that you can simply fix and test feature/1 right away, but there are various reasons in the project that make it not easy to do so. (For example, there may be a need for specification changes after testing, or the person in charge may not be available for the next 3 business days. Even if the fixes can be done quickly, there are important people who need to check it during the internal testing stage and they are not easily available.)
The feature/2 branch has passed the tests, but it cannot be released immediately in the usual flow. We need to wait for the fixes and tests on the feature/1 branch to be completed, or we need to take measures such as cherry-picking only certain commits. This is relatively easy if there are only a few branches, but it becomes quite difficult to coordinate the timing of releases when the number of developers increases and they are working on separate feature developments.
We only have one server for internal testing, and as long as we follow the procedure of releasing to production after passing the tests, I think the same problem will occur with GitHub Flow or GitLab Flow.
The New Workflow
Branch Model
The new workflow still uses three types of branches:
- develop
- The branch for internal testing. Reflected on the testing server.
- No direct commits/pushes.
- Updated by merging feature branches.
- master
- The branch for production. Reflected on the production server.
- No direct commits/pushes.
- Updated by merging feature branches.
- feature/xxx
- A local branch for developing features.
- Branched off from master.
- Created for each feature that is to be released (multiple feature branches can exist at the same time).
The biggest difference from Git-Flow is that the feature branches are always branched from master. It's similar to a hotfix branch in Git-Flow. This allows features to be released individually.
Pros
- You can release each feature individually.
- There’s no need to coordinate release timing with other people or features.
- No need to create hotfix branches.
- Since feature branches always branch off from master, they handle hotfixes the same way.
- In Git-Flow, post-release fixes involve irregular branch operations, but this method is much simpler.
Cons
- You need to manage each feature until it’s released.
- Merging into develop doesn’t automatically mean the feature will be reflected; if a feature branch is forgotten, it may never be released.
- However, if you link tasks in your task management tool with feature branches, this shouldn’t be much of a problem.
- A tip: when creating a pull request from a feature branch to develop, simultaneously create a pull request to master to avoid forgetting.
- The possibility of conflicts between features increases.
- If a feature is developed over a long period without being merged into master, it may conflict with other features during the develop merge.
- In such cases, you’ll need to coordinate with the feature branch causing the conflict.
Thoughts
- In the project I’m working on, multiple features are developed in parallel. Not having to consider others’ timelines when releasing has made the process much easier.
- As a result, whereas we previously released once every two weeks due to the hassle of coordinating everything, we’re now able to release small feature additions and fixes every two days.
- I used Gitgraph.js to create the flow diagrams. It was my first time using it, but I found it really easy!
- I wanted a name for this new flow, and I found an article referring to a similar method as "GitFeatureFlow." This name felt right to me, so I’ll be using this term from now on. 1
