I was recently discussing the benefits of automated build pipelines (sometimes mistakenly called CI pipelines). The question came up: Given the (sometimes very non-trivial) investment in building an automated build pipeline, are automated builds really appropriate for everyone?

I think the answer is no.

If you’re releasing software 100 times per day, you almost by definition need automated builds.

On the other extreme, if you release your software once ever (i.e. some throw-away one-time-use script), automation is almost certainly a huge waste of effort.

So where’s the exact line between these two alternatives?

I don’t know. I bet nobody else does, either. So here’s the approach I would advocate, adapted from How to automate anything:

1. Document your build process, so any (sufficielty trained) human can execute it. Optionally, ask random (trained) humans to follow the instructions to prove their technical and communication correctness.
2. If you discover that one specific element of the build process is especially time consuming, error prone, repetitive, or otherwise painful, automate that step. Random examples: Creating a new SSL certificate, or pinging the server until it responds after the upgrade.
3. Update the documentation.
4. Optional: Repeat from step 2.

If you follow this process, you may eventually end up with a completely automated build process. On the other hand, if you build your software so infrequently, or the process is so simple, that the gains from automation are insufficient, you’ll likely never have an automated build proces, but you won’t care.