61. 统一二进制

统一二进制

        我见过几个在构建时重写部分代码来为每个目标环境生成定制的二进制文件的项目。这往往让事情变得比它本应该的要复杂，也引入了团队可能在每次安装时没有一致的版本的风险。至少它造成了多次的构建，每个副本都只有很少的差别，而且各自必须部署到正确的位置。这意味着增加了不必要的动作，也意味着有更多可能犯错的机会。
       我曾经工作的一个团队里，每个属性的改变都必须提交做一个完整的构建过程，因而测试人员仅需要一个简单的修正版本时也需要等待（我是否也提过构建过程需要很长的时间？）。我也在一个系统管理员坚持一切从零开始重新构建的团队（使用和我们相同的脚本），这意味着我们不能证明产品中用的版本就是通过测试的版本。还有像这样的一些例子。
        规则很简单：构建一个在发布过程的所有的阶段都能识别和使用的单一的二进制文件。将特定环境的细节保持在环境中。其意思可以是，比如，将它们保持在组件窗口中，某个已知的文件中，或者路径中。
        如果你的团队有些一个会损坏代码的构建，或者将所有目标配置保存在代码中，那就说明没有人在设计过程中足够仔细地思考过，以将应用程序核心的特性和特定平台的特性分离开。可能更糟的是：团队知道该做什么，但是无法为改变提供优先。
        当然，也有一些例外：你可能是在为资源条件有些很大区别的目标进行构建，但这对我们大多数正在编写“数据库到屏幕再回到数据库”应用程序的人并不适用。或者，你可能工作的是一些遗留的、难以立马修复的混乱东西。这种情况下，你可能需要增量地行动，但开始得越快越好。
        还有一点：将环境信息也以版本记录。如果弄坏了一个环境配置，而又无法搞清楚哪里改变了，就没有比这更糟的了。环境信息应该与代码分开版本化，因为它们会以不同的速率、不同的理由改变。有些团队使用分布式版本控制系统（比如bazaar和git），因为他们让难免的回滚产品环境修改更加容易。

原文：One Binary bySteve Freeman