The branching strategy that we use as storefront international team
Branching means you create another line for your work besides the main line and continue to work there. In this way, features are kept apart from each other allowing you to fix mistakes more easily. When you are in a team, you must agree on a common strategy. A strategy that will help you deliver things continuously. The strategy may differ from your team’s needs. It can change or develop in time.
Why every team needs a branching strategy?
Software development needs continuous delivery. There should be a plan for
- when to develop features
- when to release them
- how to avoid the conflicts
how all team members can work in parallel without blocking each other.
There is when branching comes up.
- parallel development
- continuous and planned delivery
- avoid bug-free code
and it goes on.
What are the popular branching strategies?
There are several branching strategies and two of them are the most popular ones. Gitflow and Trunk-based development.
Gitflow model works with two branches: main and develop. The feature branches are long-lived than trunk-based branches. Releases derived from develop branch and after that main branch deployed. Only the hotfixes are derived from the main branch. Release-based teams can prefer the Gitflow model.
Trunk-based development where developers create short-lived branches for features and merge them within a day. It is the most useful strategy for CI/CD. CI/CD is an automation engine for your software development process. It means that a team integrate their work and is deploy the work to the production frequently.
What is our branching strategy?
As a growing team, we have lots of features that we want to integrate into the project. We are nearly 20 people as a team and there is a newcomer every month to be able to grow our team.
Our workflow is weekly where we start on Monday and develop features on Friday. That means we are working on separated and small branches, we open a pull request in a small portion. We review them as soon as possible. When it’s small, it’s easy to review changes. Consequently, it is helpful for possible conflicts between branches. We make sure the changes are bug-free with reviews and automatic controls using the GitLab pipeline.
After the pull request is merged, QA tests the developed branch and the automation tests start. If there’s a problem that exists in the feature, the developer and QA work on the issue to solve it. After everything is solved, product managers review the feature as UAT.
The bug-free developed feature now is ready for deployment. If there’s no blocker for deployment, we deploy the feature.
What are our main concerns?
- Continuous deployment and work process.
- Short-lived small branches for changes.
- Review the branches asap.
- Test them until they are bug-free and UAT accepted.
- Use automation tests and GitLab CI/CD for continuous process.
Let’s say between two features one of them is a blocker.
In that case, we have a configuration control structure. At the beginning or during the process if a blocker happens, we add an if-control. When it is useful?
- The feature might be related to other teams and until everything is resolved, we delay the deployment. However, with an if-control structure, we are able to deploy and open the feature config when it’s ready.
- It can happen between features and in this way, none of them blocks each other.
How do we handle the review process?
By using GitLab features, we have a rule that after two developers approve, it can be merged. Our aim is to prevent
- possible errors, especially coming from javascript
- it’s a fit for our development standard document
- to discuss if there’s a better approach for a particular thing
Therefore when it’s merged, we are sure the changes are ready for the tests.
And one of the important parts of the process is we monitor after the deployment. We make sure there’s no problem exists and if exists we take an action immediately to solve, thusly. Deploying small changes are helpful to prevent these scenarios.
You can ask these questions when you want to choose a branching strategy?
- What is our continuous deployment process? ( How often do we deploy? )
- Is our team growing or in the mature stage?
- How do we handle the review, automation and monitoring process?
If you want to deep down you can visit these titles:
We are storefront international team who develops Trendyol International website’s frontend software, and we would like to add new talents to our team.
If you would want to work with a team who develops frontend software using React, Typescript and implements BFF and microfrontends architecture, and also loves to write tests, you can contact us.
