3 ms·

Alternatively, you can parallelise parts of your build (eg the tests, static analysis etc) and speed it up. Then, if you have more changes coming in than you co

Alternatively, you can parallelise parts of your build (eg the tests, static analysis etc) and speed it up. Then, if you have more changes coming in than you could parallelise is when you can start to do some advanced things like trying to predict which changes might break the build. There was a longer discussion on one of these approaches done by Uber[1] on HN. Granted it’s a lot of investment, it’s interesting to explore ways of dealing with long builds that need to run frequently. https://news.ycombinator.com/item?id=19692820 https://news.ycombinator.com/item?id=19692820

royosherove 6y ago
True, but that type of optimization is quite moot if you're only running the build at night (i.e, that's not the first constraint to solve). In the article I mention that first get the builds to be tight one after another, then work on build times because that becomes the constraint.
larrybud 6y ago
Or, just parallelize the entire build. eg, if you have four build servers, you could kick off a build every hour. Easy using VM's, trivial in the cloud.