At Netguru, we keep everything on a master branch and deploy as often as we can. Our code review process works on commit by commit basis, and you have to get your code reviewed by somebody, or else your build will fail.
Part 1 is just a set of observations we have made, when joining projects with other development teams on our clients projects.
Our default flow is described below - it's very different from FB / PR flows, so we try not to enforce it - when joining a project you want to have as little takeover traction as possible. Another blog post on that is on it's way - but it's safe to say we can follow what's described here in 9 out of 10 projects we do.
Right now netguru team is 50+ in size, average project team size is 2 (currently the maximum is 4). We have seen this flow working well last year on the project team that varied from 10 to 14 people.
This is what our review looks like:
The grey labels are JIRA tickets to give you more context. You click the eye icon to open the commit preview on github, and use the dropdown menu to change commit state.
This means you can push your code instantly to production if you need too, but in less than 2 days somebody will have to take a look at it.
Some insights from Wiktor on this flow can be found here: strict peer code review
Apart from this review, inside project team developers often use compare view to see what's going to be deployed, just for the final check. Since we deploy often (ideally at least once a day) the scope should not ever be too big to comprehend.
In this kind of workflow where everybody trades with everybody, you can see how different and great the possibilities are:
We have even started doing internal review webinars over Google Hangouts, to show the newcomers how picky can you get in your review. This is speeds up the knowledge flow even more.
For Netguru as a company, this also means that we were able to grow from 5 to 50, and we are not scared of losing our project quality when we think of doubling our size. Core rules of this flow (single branch, commit by commit review, failed builds on rejected commits) were established in our company 4 years ago - and worked out great for us.
To make sure bigger features or refactorings don't get in our way, we use feature flags in our code. Usally it's as simple as a features.yml config file, but you can get sophisticated with tools like flip to mark your work as not ready.
There are different approaches to this subject, and extrimist can always disect the whole project into smaller feature apps. The general approach we always want to remember and follow is:
"Feature Branching is a poor man's modular architecture" - Dan Bodart
Read more about it in blog post by Martin Flower
To wrap this up, what we value the most is:
We often feel that pull requests with features are like handbrakes for those values. It feels horrible when you have to wait for someone’s acceptance before your code gets to master and others can use it. This implies lack of trust in your work. We trust each other, we review to get a second coder’s eyes and correct course, without ever halting our workflow.
Make sure to read first part of the post too - Ups & Downs of Pull Requests Flow Part I (pull request flow traps, sad stories).