Branching policy at Feather
This article is part of our internal documentation at Feather. We build our product in the open and share our learnings with the community. We’re always looking for talents to join our team check out our careers page!
There are many different great articles on branching strategies and how to choose them. In this article, I’ll be talking about the current branching policy at Feather and the reasoning behind our choices.
We started off by using the GitHub flow with two branches deploying to two different environments. The main branch and the dev branch. Every commit pushed on dev triggers a staging deployment and every commit pushed on main triggers a production deployment. But in one of our retrospectives, we realized that we could improve on that.
The workflow was the following:
We believe in merging as early as possible. This helps us deploy to production faster, but comes at a price of invalidating the staging environment — and QA results — too often.
We decided to go with a solution where we could be confident enough to deploy at any time.
We heavily invest in testing
Whenever we make a change to the codebase, we need to be confident that it won’t break anything. This means that we need to heavily invest in testing (unit testing, visual regression testing, end-to-end testing…).
We merge early and small with the help of feature flags
It’s really important to avoid massive pull requests in order to get quick and efficient code reviews from your peers. A huge feature will get incrementally incorporated in the codebase with small and reviewable commits. When this feature is ready to go to production it’s only a matter of flipping a boolean value or adding a few lines of code (e.g. to make the endpoint public).
We moved to trunk based development
We realized that with the current setup we didn’t gain anything from using GitFlow. We came to the conclusion that moving to trunk based development — where developers collaborate on code in a single branch called trunk) — will allow us to have a tidy, linear Git history, force us to be stricter with our testing coverage, and is more straightforward to work with.
Check out our Deploying our code at Feather to know more about how we manage releases.
Related resources
