As you probably know, there are two ways of dealing with Git development: one assumes that you push everything to master (single branch flow), and the second is all about multiple branches (multi branch flow). In this blogpost, I would like to share netguru’s story about migrating from one flow to another.
Just to remind you of a few things from the past - before 2016 we were true believers in single branch flow. We shared our views in blog posts about the ups and downs of pull request flow (part 1 and part 2). But we can’t be slaves to our own decisions, so we’ve taken another look at how we push our code to the world.
We also felt that our code review process could be improved. We were checking ALL the commits pushed to master, even if they had been changed a couple of minutes after the review. Those commits had to be very small so that we could check them one-by-one and understand what a particular change does. This forced us to be very strict and caused a lot of pain when we had to wrap our head around a series of commits and check them independently, instead of reviewing them as one change to the codebase.
And then there was the problem of delivering multiple different features all at once when one was finished, and the other was still “work in progress”. It was very hard to develop this way, and we had to hack the system using feature flags which weren’t designed with this purpose in mind.
Now we push all our commits to feature branches, we create Pull Requests when they’re ready, and this is where all the good things start to happen:
In comparison to single branch flow, we found a few flaws:
But making changes to branches isn’t the only thing we introduced with the migration to Pull Requests. We introduced some new tools/approaches to our flow so that we can get the most out of it.
Apart from changes in the way we do commits, we’ve also migrated to a docker-based devops stack. It turned out that creating a new environment for the app is quite easy. Thanks to this, with every opened Pull Request - we automatically build an integration environment containing code only from that PR. We use a modified version of Heaven, which builds a fresh app available at a specific URL.
With reasonable seeds (sample data) in place, it’s a really nice way to test things out - we won’t ruin somebody’s data, we can mess with the app and data as we want and make sure it works as expected before we introduce changes to the master branch.
When a dev finishes their work, they just give the QA a green light to test things out in real life. After the QA accepts the change, we’re ready to merge the feature branch to master and deploy it on production.
And yeah, this requires that a fresh set of sample data is created every time a new version of the app is deployed. This a good thing, because it means that our app is ready to be picked up by another developer with minimal setup - we can introduce new developers to the app very quickly.
We love Slack, and we couldn’t resist writing an integration for Pull Requests. Our approach might be a little different to that of other teams because there’s a lot of people in our team and a large number of Pull Requests opened every day.
Each Pull Request has to be reviewed by someone before it gets merged. Sometimes there’s no more than 1 dev on the team; sometimes we want a fresh pair of eyes (someone outside the project) to see if the changes we want to introduce are easy to understand. So we built a tool which helps us to see which Pull Requests are available for review so we can trade our PR with other people. Here’s how it looks:
There will be a detailed blog post soon where you’ll be able to read more about this integration, but for now - you can go directly to the repo containing all the stuff you need.
In order to move through the Pull Request lifecycle, we’ve agreed on a few default labels which we use in our projects:
We love the way you can hook up 3rd party integrations to Pull Requests and check many different aspects of the PRs! You can see an example of the status of one of our projects in this image:
Most of the time we use the following integrations:
I hope you found this article useful - we wanted to share our way of using Github and Pull Requests. If you have any questions or suggestions about how we could improve our method even further - don’t hesitate to let us know!
And remember: no tool will solve all code review problems. The key to a great review process is to keep everything clean, short and well explained - reviewing such chunks of changes is much easier and results in a better, higher quality analysis. It’s a lot easier to focus for 10 minutes than to focus for an hour.