我遇到过几个项目，其中的构建代码会重写一部分，以便为不同的目标环境生成对应的二进制文件。这总是会让事情变得比它原来更复杂，并带来一个风险——对于每个安装包，团队可能都没有个统一的版本号。至少，这些多个编译目标几乎都是该软件的副本，只不过被部署到了不同的地方。这就意味着很多不必要的部分也被移植过去，也意味着错误的可能性更高。
我曾在一个团队中工作过，每个特性变更时都不得不进行一次完整的构建周期检查，因此每次微调时测试员都得随时待命（我有提到过构建时间也很长吗？）。我还在另一个团队中工作过，那里的系统管理员坚持要求在生产环境重新构建（使用我们的脚本），这就意味着我们无法证明生产版本是经过测试的。等等吧。
规则很简单：只构建一个二进制文件，你能够在发布管道内进行所有阶段的识别和升级。保持环境的具体细节在环境中。比如，把它们放进一个组件容器、或已知的文件、或路径。
如果你的团队将代码分离编译或是将所有目标平台设置存到代码里，那就说明这是一个没有经过慎重考虑的设计，不足以将应用程序的核心部分与平台细节分离开。另一种可能：团队知道怎么做，但不能先试着去改变。
当然，也有例外：你可能在为有着显著资源限制区别的目标平台做构建，但这并不适用于我们大多数编写“数据库筛查和返回”应用程序的人。又或者，你可能正遇到一些难以立刻修复的遗留问题。这种情况下，不得不逐步前行——但最好尽快开始。
还有一件事：也要确保环境信息的版本化。没什么比破坏环境配置和搞不清哪里被修改更糟糕的了。环境信息应当独立与代码进行版本化，因为它们会以不同的频率和原因发生变化。一些团队会采用分布式版本控制系统来进行管理（比如bazaar和git），因为它们很容易在生产环境中作出变更——必然的——也能回退到仓库。
