945
《配置管理最佳实践》——2.4 建立构建职能的注意事项
本节书摘来自异步社区《配置管理最佳实践》一书中的第2章，第2.4节，作者： 【美】Bob Aiello , Leslie Sachs着，更多章节内容可以访问云栖社区“异步社区”公众号查看
2.4 建立构建职能的注意事项
根据我的经验，在开发团队中实施构建工程最佳实践之前，必须要打消大家的疑虑。有时，对现有构建过程复杂度认识不足，可能会导致人为错误、代码缺陷、不断返工、生产效率低等问题。造成这种现象的大部分原因都是技术上的，另外可能是过程上的。而一旦有问题，就会有人把责任推到构建过程上来，建议简化构建过程。曾经遇到过在某产品中使用的技术特别复杂，而专业技术人员深陷于复杂的技术泥潭之中，并把它弄得更复杂了。显然，我们都希望尽可能地把事情变简单，做到万无一失。但是现实情况是，很多专业技术人员都想通过能处理复杂问题来显示他们的实力，结果把问题弄得更复杂了。
2.4.1 推广独立构建
独立构建可以验证代码库中基线的配置项。通常监管部门都要求有独立构建，以降低任何可能带来问题的风险。也就是说，构建工程师要说服开发团队改变一些构建过程，来避免可能出现的错误。开发人员认为构建工程师从头开始重新构建一遍应用太浪费时间。也许开发团队知道在产品被提交到QA或者生产环境之前要通过独立的环境进行构建是监管的要求，但是很多工程师还是会窃笑，觉得这项任务就是浪费时间。如果构建工程师是开发团队中的一员，这将有助于理解构建当中涉及的技术问题，但是这样常常会把自己放到一个尴尬的位置。很多时候，构建工程师都要和开发团队进行妥协。总之，管理层应该在公司规章制度允许的情况下，让构建工程师可以尽快地得到他们想要的信息。构建过程要尽可能地快并且自动化，这样其他人不需要等很长时间就能得到想要的东西。为了做到这一点，构建工程师应该负责第一时间查看和解决构建中的问题。
在构建的工作中经常会遇到的问题是构建过程过度工程化，导致构建过程太复杂。通常情况下，公司有一些工作已经自动化了，但是其中仍有很多让人头疼的部分，以致没有一个人懂得这个构建到底是怎么工作的。这就导致公司里的其他人不敢修改，更无法提供支持。通常来说，这就是构建过程过度工程化的直接结果。下一节，我会分享我是如何解决这个问题的。
2.4.2 过度工程化构建
我发现很多公司不可靠、太复杂的构建工程已经严重阻碍了其开发工作。接连不断构建失败警示我们这个团队可能无法成功地发布一个版本，这成了项目和公司最大的风险。有时候这都是由于软件配置管理做得差或者几乎没起到配置管理的作用导致的。但是更多时候是因为构建脚本本身太复杂，几乎无法维护造成的。通常的问题是一个很聪明的人创造了一套非常复杂的构建过程，团队里其他任何人几乎都无法理解这套过程和自动化程序，更无法进行支持。常见的情况是，构建工程师尝试使用构建功能时，他希望可以传进去一个变量作为参数（例如，开发、QA或者生产三个值），这时就可以根据参数生成需要的配置文件。在第3章中，我们将会详细介绍一些关于创建配置文件的最佳实践。而开发者设计构建工具的时候，他希望相同的代码可以运行在各个环境当中（例如，开发环境、QA环境和生产环境）。但是他基本上不了解软件测试的过程，也不了解生产环境下部署和配置的情况。因此，软件测试时用的是一个版本构建，而当我们把产品部署到生产环境下时，却用了另外一个版本。这是一个很大的问题。我们一定要确保软件测试和生产环境下使用的是同一版本的源代码，例如都是从基线发布出去的。但为每个环境都重新构建，这显然是不现实的做法，因为这种情况下可能绕过IT的控制，而且没有进行一致性评估。还有一个常见的问题就是，在构建过程中同样的文件被放到不同地方，名字一样，但是大小却不一样。这会让看到的人相当费解。之所以那些聪明勤劳的工程师开发出来的系统这么复杂、这么难理解，是因为他们根本没有从软件测试的角度考虑需求或者不理解这个工具的本质需求。
2.4.3 保持正直和诚实
有些时候, 公司管理层要求做的事，并不都是完全正确的。一次，某大银行要求我保证所有的开发团队都是符合2002版萨班斯法案404节IT监管要求的。在这种情况下，我的责任是审查所有团队，要求所有开发团队都要依据ISACA1Cobit2模型的要求，建立合适的变更和配置管理流程。这项工作对于我这种配置管理狂热分子来说是再兴奋不过的事了，我帮助他们满足了合规要求的同时，还提高了产品的质量和工作效率。我在项目最后阶段也加入到了这个项目。项目要在一段很紧张的时间内完成SOX法案3的合规要求。这时我的老板，SOX法案的合规专员和我一起开会，当我提出要为每个团队做配置管理评估的时候，他们都非常吃惊。他们认为审查是否符合SOX法案才是第一位的。这一次虽然他们有些不了解我的做法，但是我成功地说服他们同意我去做配置管理评估。评估结果是四分之三的团队都使用了正确的软件配置管理流程。然后我请求给予更多的时间进行审查，最终的结果是他们都是合规的。六个月后再次做审查时，我发现一些团队已经倒退，重新拾起了先前的做法。我觉得这已经不是技术能解决的问题了，而是一个办公室的政治问题，所以我最终离开了这个公司。不久，这个大型金融服务公司就倒闭了。我觉得倒闭的原因在很大程度上是公司短视，太关注短期目标，偷工减料，最终酿成了灾难。就如同当年的安然事件一样，但是我会尽力让公司做正确的事情，并符合所有行业法规。
2.4.4 隶属研发部门引起的利益冲突
另外一个实例是，研发团队的头儿是我的直接领导，而我帮助团队构建和部署一个大型的国际贸易系统。这个系统用的技术十分复杂，因为我和研发团队一起工作，理解这个系统的速度快了很多。我们一遍又一遍地构建、发布和部署交易系统，从未发布和部署过失败的构建。然而，项目截止日期日益临近，甚至都已经发展到按时发布产品和研发部门经理奖金挂勾的情况。研发团队不断地修复缺陷，然后构建，最后部署上去，一遍又一遍地进行着。上线的截止日期到了，我却被要求去部署一个因含有缺陷而未经过QA团队核实的系统。也就是说，我们测试了系统的某个版本A，并得到QA团队的批准，可以进行部署；但是实际上我们部署的却是另外一个版本B。我找到研发部门的头儿，也就是我的直接领导，解释说我们不能构建和部署一个未经QA团队批准的版本。他当然不希望因为错过最后期限而丢了丰厚的奖金，所以他坚持发布这个版本。无可奈何，只好找到他的直接老板并解释了事情的原委。他的老板当即表示，最新的版本应该走正常的测试流程，必须要经过QA团队的确认才可以上线。因此，项目延期两个星期，但是我们遵守了正确的流程，避免了上线后可能出现的问题。可是从此以后，这个研发团队的头儿觉得我是在和他对着干，而不再配合我，我的工作也就变得很难进行下去了。
2.4.5 组织结构的选择
在理想的情况下，构建工程团队应该向足够高级别的管理层汇报，避免自己受到办公室政治和那些只关注自己利益经理的影响。经常看到构建团队是QA团队的一部分，但是远离开发团队会阻碍交流合作，以致无法快速有效地理解要构建的系统。因为在部署应用程序的时候我的职责和系统管理员（SA， system administration）的职责有些重叠，所以我需要同时向系统管理部门和数据安全部门的经理汇报。还有很多其他的组织结构，但是无论哪种组织结构，都要确保构建工程师可以得到他们所需要的信息，经授权后可以去操作，以便有效地保护公司的资产。同样重要的是，构建工程团队负责人应该是一个遇到问题愿意去沟通的人，如果有必要，也是敢于说不的人。比如版本中还有严重的问题没有修复，在这种情况下就不能发布版本给客户。我个人的经验是，构建工程师是一个十分具有挑战性的职位，需要高级管理层提供必要的支持，以便构建工程团队可以做好自己的本职工作，保护好公司的重要资产。
1信息系统审计与控制协会（ISACA，Information Systems Audit and Control Association）是全球公认的信息科技管治、监控、保安以及标准合规的领导组织。
2COBIT(Control Objectives for Information and related Technology) 是目前国际上通用的信息系统审计的标准，由信息系统审计与控制协会在1996年公布。这是一个在国际上公认的、权威的安全与信息技术管理和控制的标准。
3SOX即《萨班斯法案》（Sarbanes-Oxley Act）的简称。 萨班斯法案是美国政府出台的一部涉及会计职业监管、公司治理、证券市场监管等方面改革的重要法律。萨班斯法案为公众公司的外部审计师创建了一个新的监督体制，并把对财务报告的内部控制作为关注的具体内容，不仅要求管理层报告公司对财务报告的内部控制，而且要求外部审计师证实管理层报告的准确性。
最后更新：2017-06-05 10:01:46