1. 14
  1.  

  2. 2

    Wow! They don’t do branching. That blew my mind. But the way that they avoid having to branch is by an enormous amount of testing, about 14K tests in total. This is interesting, and I’m curious if it’d work in practice elsewhere. I wonder how they run policy on development, specifically about repositories and keeping things up-to-date. It doesn’t take a few hours to write some big features for Chromium, so what do people do when they have to actually merge their changes in?

    1. 2

      The runtime switches / feature flags / etc. are the main reason you can get away without branches, even for large changes. Firefox development also follows a similar flow to what’s described here.

      In many cases, you can land small pieces so you’re always integrating with trunk / master / the main thing. But for more complex things, you add a feature flag so your feature is disabled for the general user population, but you can still land your code, add unit / integration tests, etc. Then just keep building on that in successive patches until it’s complete enough to enable for users by flipping the flag on.

      1. 1

        Wow, a reply from a Firefox developer! Awesome. This is all very interesting, especially from my perspective of being a university student where I’m told that people do primarily branching in industry and that alternatives won’t work.

        1. 4

          You can read more about this approach to software development by searching for “Continuous Delivery”: https://en.wikipedia.org/wiki/Continuous_delivery. It’s quite common with web services, and less common in client-side (particularly mobile) software - mainly because it’s harder to do continuous autoupdate with client-side software.

          1. 2

            From long experience, I’d even say that branching doesn’t work, or at least works very poorly. Case in point, at work we have dozens (maybe even 100) branches going at any one point, where each commit on each branch needs to run through many tens of thousands of tests, which therefore requires hundreds of machines to run the tests sufficiently in parallel to get a reasonable response time (and by “reasonable”, I mean 60-90 minutes). It’s all incredibly wasteful, and can take weeks for changes from one team to be absorbed by another team. I often feel that we’ve enabled this by spending lots of money on the test machines, but it’s so easy to just become adapted to “that’s just the way things are”.

            1. 1

              I don’t do a lot of product work anymore, but I have a side project I’m hoping to get into production soon. Each time I push a commit to GitHub, Travis picks it up, runs my tests, and if they pass, deploys straight to Heroku. 100% automated.

              People work like this to varying extremes. Some people only deploy once a month or once a week, but I really like to deploy all the time.

        2. 2

          This is very similar to how we develop Rust, except the “commit queue” is mandatory. Bors works hard.

          It’s a really enjoyable way to work.