This post expands on a section in my Writing Code That Lasts Forever talk.
Here's what it takes to release a new version of OkHttp:
- Confirm the code is in a releasable state!
- Name the version (5.0.0-alpha.10 ?, ick)
- Summarize what’s new in the changelog
- Tag the release in git
- Build, sign, and upload artifacts
- Promote on Maven Central
- Post updated API docs to the web
- Announce on Mastodon & Twitter
Some steps are automated and some aren’t! What is automated varies by project. Automating processes like this is good 'cause it saves time & increases consistency.
But something else happens as we automate more of this process: we release more frequently! When cutting a release takes 20 minutes instead of 60, it stops being sacred.
It Cuts Both Ways
At my job we're a years-long slog to replace our monolith with microservices. Creating a new microservice was a grueling process (create a git repo, roles, permissions, provisioning, etc.) so one of our consistency-loving engineers automated the whole process.
That was awesome! A process that used to take days of careful configuration started taking minutes.
But within a few months, we found ourselves with hundreds of unnecessary microservices! By making service creation so easy, we induced lots of demand.
This is similar to the Induced Demand of adding new lanes to expressways. By continuously and aggressively lowering the cost of travelling by car, America has metastasized into an automotive hellscape.
Induce What You Want
Do you want more frequent releases? Of your libraries, your mobile apps, or your cloud services? Automate the release process!
Do you want more test coverage? Improve your test infrastructure so that tests are easier to write and faster to run! (Paparazzi induced thousands of screenshot tests in our codebase; it’s amazing.)
Do you want to eat more vegetables? Buy pre-cut veggie trays so the time from hunger-to-celery is zero.