本节书摘来自异步社区《配置管理最佳实践》一书中的第2章，第2.7节，作者： 【美】Bob Aiello , Leslie Sachs著，更多章节内容可以访问云栖社区“异步社区”公众号查看
2.7 把构建做得更好
在很多公司，已经建立了良好的构建流程，我的角色就是帮助改善现有流程，以支持更多的环境（比如QA环境和生产环境）。有段时间，我发现有的构建过程只有技术背景很强的专业技术人员才能理解和使用好，且在使用中极易出错，结果也不可靠。构建工程的目的是提供一个可靠、快速、清晰的构建过程来支持产品的构建和部署。
2.7.1 鲍勃的构建秘方
这一小节将介绍建立可靠的、可重复的构建过程的秘诀。在很多环境中，我的方法都可以帮助开发团队成功地完成构建，并且部署到QA环境（生产环境）中去。通常情况下，我都是在项目或者公司濒临失败时才加入其中。如果采用我的方法，通常可以在3个构建之内解决他们的构建问题。我的很多技术都是基于在纽约大学工业组织心理学研究生课程中学到的方法。在其他学科学到的知识帮助我建立了一套独特的方法。团队失败的原因有很多，只要是构建工程的问题都可以通过改进构建来解决。
2.7.2 测试驱动的构建
构建工程师不仅要随时关注构建的过程，还要关注开发人员调试构建、解决构建问题的方法，甚至是每一步的操作。有这样一个实例，我观察到每当构建失败，开发人员就会查看某个特定的 JAR 文件是否被创建，是否包含在了 WAR 文件当中。我并不完全了解为什么有的时候这个 JAR 文件没有被创建成功。之后在构建脚本中，我也加入了这一步骤，在以后的每次构建中，构建脚本都会检查这个JAR文件是否存在。如果某步检查到这个 JAR 文件没有成功生成，那么构建脚本就会提前通知我们，JAR文件缺失将会导致构建失败。虽然这样做可能有点小题大做，但是主动测试构建将会帮助你生成可靠的构建，并且一旦出现错误你也会很早就得到提示。开发人员一般都坚信自己的构建是完全没问题的，因此并不会主动地去测试自己的构建。
2.7.3 信任，但仍要核查
作为构建工程师，我的做法是“信任，但仍要核查”。也就是说我们信任生成的每个构建，但仍然需要对它们进行测试。当你的构建结果事关他人的健康和安全时，这就尤其重要。也许一个构建的错误可能就会导致飞机相撞或者其他更严重的事件。他人的健康和安全都是至关重要的事情。例如，航空工程师花费了大量时间制造准确、易理解的控制器，以避免出现问题。
2.7.4 飞机的驾驶舱
在某些领域，经常需要付出大量的努力去避免可能出现的错误。之所以这样关注整体质量，是因为任何一个错误都可能导致有人丧生。就像本节前面讨论的一样，采用这样的思路设计驾驶员座舱就是为了减少错误的发生。上面的控制器都容易理解，接口也很清晰。我觉得软件工程师需要向飞机驾驶舱设计师学习，把它应用到应用程序构建、部署过程和自动化的设计上。曾经尝试创建可以避免错误，且可以主动检测构建问题的构建系统。构建和部署的自动化需要想办法避免可能的错误发生。我做过多次构建工程改进的项目，每次都是把团队从不稳定、不可靠的构建状态中解救出来，成功地实现一个完全可重复的可靠的流程。下面列出来一些重要的关注点，供设计或改进构建系统时参考：
- 构建过程的每一步都要易读且易执行
- 自动检查构建过程中可能的出错点，核实构建是否成功
- 结构化组织自动构建过程，避免一个错误破坏整个构建
- 通过状态公告板和构建报告展示构建状态
