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 seems to make thing more complicated than they need be, and introduces a risk that the team may not have consistent versions on each installation. At a minimum 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 might mean in the component container settings, a known file, or the path. Of course there are exceptions, say where you're building for targets that have significantly different resource constraints, but they don't apply to the majority of us who are writing "database to screen and back again" applications. If you do have a code-mangling build, then it suggests that either the team hasn't thought through its design enough to figure out which parts of the system move where or, worse, that the team has but cannot find the time to make the changes.
And one more thing: Keep the environment information versioned too. Some teams like to keep the settings in the same repository as the code; some like a different repository. There are advantages to both.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page