2.3 构建工程的核心概念
成功的构建工程都包含如下职责：首先构建的依赖关系易被理解且受控，基线是可识别的，在此基础上可重复地生成构建。每次构建都是针对配置项的活动。构建包含配置项，并且可产生新的配置项。几乎构建中的任何东西都可以被认为是配置项。构建工程师的首要任务，是核实所有的可执行文件、重要的脚本、文档和文本文件已被正确地识别和标识。
2.3.1 版本ID和标记可执行文件
构建工程师既能轻而易举地识别出源代码基线，也能轻松地确定构建产物的版本。这包括所有的二进制文件（中间代码和运行时模块）以及所有的配置文件。正如第1章配置管理术语中提到的，我们称这些产物为配置项，无论它们是源代码、二进制文件还是配置文件。在理想的情况下，一切事物都有一个不变的版本ID作为标识。实际上我们已经习惯了通过查看应用程序的“关于”框看产品的版本。所有的文档，包括发布说明、教程和技术说明等，都应该包含版本信息。这样，我们就能很容易地知道它们对应的是源代码的哪一个版本。
2.3.2 不可变的版本ID
对可执行文件最基本的要求就是给它们一个不可变的版本ID，然后提供简单的程序来检索版本ID。对于C++程序，通常可以把版本ID设置成一个静态的char 类型变量，然后把它打在可执行文件上。对于JAVA程序，可以写一个JAVA类去定义版本ID，然后把版本ID写到构建过程生成的JAR,WAR, 或EAR的 manifest文件中去。关键在于确保通过可执行程序的版本ID可以很容易地追溯到生成它的源代码版本。
2.3.3 打上版本标记或者标签
在某些情况下，发布构建的时候，我们会把源代码管理工具的版本标签或者标记打在可执行文件上。因为在源代码原理工具中，当用于发布的构建标签或者标记被锁定时，基于标签或者标记的构建也就确定了。那么当需要重新构建时，我们就可以基于这些信息重新构建出基线版本。某些时候，标签或者标记不容易被锁定，很容易被认为是开发人员删除了标签或者标记，然后把另外一个版本的代码附加到先前的标签或者标记上。此时，如果构建已经准备发布给QA了，那么我们就要记录下当前版本库的修订版本。
更改两行修复缺陷
好的构建工程实践可以让你很容易地识别出发布的构建是由哪个版本的代码生成的。也就是说，看一眼生产环境下正在运行的可执行文件，就可以确定是哪个版本的代码生成的这个发布。如果坚持遵循这一最佳实践，修复缺陷时就可以随时创建一个沙箱(sandbox)，然后从代码基线获取正确的版本，更改两行就可以解决了。
在遇到头文件版本错误或一些编译依赖问题时就可以确定根本不需要代码回滚， 改两行代码就可以修复。这种做法十分方便和高效。
2.3.4 管理编译依赖
很多构建失败都是由于环境问题造成的。比如某个环境变量是用某开发人员的账号设置的，而两个月过后准备发布代码时，在正式环境下用其他账户构建时就会失败。不仅仅是源代码，所有的编译和运行时依赖都必须被了解且受控。这就意味着每次构建时，构建脚本必须设置所有的环境变量，以确保所有的构建依赖都是正确的。
2.3.5 独立构建
避免出现严重错误的办法之一就是独立构建每个发布版本，并且每次构建都是从顶级到下级，所有配置项都重新构建。这通常由一个独立的版本发布管理团队完成，或者由持续集成中的自动构建过程完成。许多规章制度不但明确要求职责分离，而且要求有独立的构建、打包和发布控制过程。看起来好像有很多工作，但是从合规的角度来说，这是一个最基本的要求，大多数金融服务公司、国防部门、医疗部门和政府机构都有这样的要求。曾经有一个研发经理实施了我的最佳实践后，很快地就建立沙箱，获取基线，快速修复问题并部署到生产环境中。他对这种做法非常高兴和兴奋，以前需要很多时间才能解决的问题，通过实施适当的IT控制就可以迅速做出反应。我们将会在第13章详细讨论限制访问生产环境。本书后面还会提到一些其他提高生产效率和质量的实践。