Posted 2021-03-02 23:00:00 GMT
Compute is elastic now so running 1 job for 1000 minutes costs as much as 1000 jobs for 1 minute. The primary resource to conserve in the software life-cycle is developer time: something non-linear to do with developer attention - if you make someone wait five minutes they'll go off and do something else. Ideally, you want to speed up the observe-orient-decide-act-loop with quick feedback.
The quickest feedback comes from compilation and small fast tests (not getting into religious wars about what qualifies a test to be a unit test). However, this feedback is very incomplete and the faster you can get to a real test (e.g. canary) the better. Instagram boasts about rapid deploy cycles.
How to reconcile this with the complex dependency graph of modern software deployment? It's just not possible to force everybody into the same repository or build system. A change in one library might affect a big graph of downstream projects. Companies that try to run monorepos often have software straggling into github.
There is a broadening radius of passing tests and releases as code is pulled into more and more deployments. Rather than fight this reality, a build system should acknowledge it. Branches should melt into each other when tests pass and releases are signed off. Builds happen rapidly, cache their inputs and it's immediate and fast to start images for a given build.
Post a comment