(^122) 97 Things Every Programmer Should Know
One Binary
Steve Freeman
i’VE SEEN SEVERAL PROjECTS where the build rewrites some part of the
code to generate a custom binary for each target environment. This always
makes things more complicated than they should be, and introduces a risk
that the team may not have consistent versions on each installation. At a mini-
mum, it involves building multiple, near-identical copies of the software, each
of which then has to be deployed to the right place. It means more moving
parts than necessary, which means more opportunities to make a mistake.
I once worked on a team where every property change had to be checked in
for a full build cycle, so the testers were left waiting whenever they needed
a minor adjustment (did I mention that the build took too long as well?). I
also worked on a team where the system administrators insisted on rebuilding
from scratch for production (using the same scripts that we did), which meant
that we had no proof that the version in production was the one that had been
through testing. And so on.
The rule is simple: Build a single binary that you can identify and promote
through all the stages in the release pipeline. Hold environment-specific
details in the environment. This could mean, for example, keeping them in
the component container, in a known file, or in the path.