【IT168 技术文章】
本文来自于 Rational Edge：构建管理通常是横跨多个软件开发规程，并且是易于出错的，通过大规模的手工过程来执行。本文探究将关于大规模项目的构建管理活动自动化的方法，然后介绍 IBM Rational Build Forge 的自动构建及发布管理技术，以及改进的软件质量技术。
对于希望在整个软件开发生命周期中高质量且有效地构建软件的组织来说，构建管理的领域是在最后的边界之间。将软件系统的所有部分装配成可部署的、可使用的产品的过程需要许多步骤，并且涉及多个规程，包括开发、配置管理、测试和发布管理。虽然那些规程中的活动可能自动化程度很高，但是它们之间常常没有相互作用。
在较小的项目中，这种缺乏跨规程的自动化可能不是使人虚弱的问题。但是当应用变得越来越复杂、跨平台，并且是面向服务的，以及当团队越来越大，并且是地理上分散的时候，当今简陋的、且大量手工构建的过程开始被取缔了，构建并测试产品的任务越来越不可预测，并且很难重复。成本和进度上的风险可以达到无法接受的水平。
大家公认的是，开发团队经常花费大量时间来诊断构建过程中突然出现的错误 —— 有时候，比分离出错误的原因后对代码进行修整所花费的时间还长。同样，团队经常花费过多的时间来维护并过分小心地对待他们的脚本驱动的构建系统。这种级别的人工干涉不可避免地妨碍团队的生产力，并降低产品质量。问题是：对于这种情况能做些什么？
在本文中，我将着眼于现今的构建管理过程经常怎样工作，并且探究在企业范围内的开发工作中有效地将该过程自动化的几种方法。最后，我将讨论用于将任何大小的环境中的构建及发布管理自动化的 IBM® Rational® Build Forge™ 的重要能力。
更大、更好、更快、更多
遇到逐步上升的行业趋势的冲突时，开发组织需要满足似乎互斥的目标：即使是在软件产品和软件开发环境都更加快速地复杂化的情况下，还要增加产品质量，并加速向市场投放。
许多推动因素增加了这些困难，关键的是：
.面向服务的架构（service-oriented architecture，SOA）和 web 服务的出现，它们可以集成多个、可复用的软件组件，从而创建更大，更成熟的应用程序
.法规遵循的增强，这可能要求详细的跨开发生命周期的活动的审计记录
.分布式开发的大量增加，包括各种形式的外包，这作为一种减少成本，并压缩市场投放时间的方法
由于这些和其他因素，开发团队必须更加有效率、更加敏捷，并且更面向质量。这意味着提高软件开发生命周期中过程自动化和集成的效率及有效性是不可避免的。越来越多的组织为了自动化而瞄准的领域是构建管理。
不难看出存在改进构建过程的一般需求。作为开发和发布管理规程之间的夹层，构建管理活动会因为现有工具集之间的裂缝而失败。 每个规程都包括，将所有事情都放在一次构建中（开发、配置管理、测试、发布管理，等等），用其首选的工具进行活动，并且经常进行成熟、结构良好的过程）。但缺少的是跨所有规程集成的质量。这是成问题的，因为成熟的构建管理对整个团队效率是至关重要的。如果您不能足够频繁地“改变不稳定的构建”，那么开发和测试都将遭受痛苦。
类似 IBM Rational Unified Process®（RUP®）的方法为跨规程的开发活动的协调提供了非常好的实践指导，但直到现在，也几乎不存在可以帮助让该指导应用于企业范围的解决方案。
典型的构建管理缺点
许多构建管理系统本质上都是自制的，并且已经随着时间演进了。团队经常通过构建脚本来将它们的构建及发布过程自动化，然而，这些脚本驱动的系统很少适用于表现出现代软件开发特点的日益大型、复杂，且分布式的环境。常常每个任务都独立地运作，因此需要嵌入等待时间，并且适当地协调 —— 通常是手动地。在这种场景中，一个每夜都崩溃的构建可以很容易地说明，QA 人员只能在第二天闲坐着，失去了宝贵的测试时间，而开发和构建团队却在寻找错误故障。
当一个功能将可交付产品传给其他功能时，经常出现错误的大的空白。每个规程中的团队成员，通常都进行一些相对于其他规程来说有点自主的操作，在这种意义上来说，他们关注自己的核心能力，而不是他们的工作与整个产品构建过程之间的连接。因此，有时候当构建产品时，左手可能不知道右手在干什么。缺少一致、可重复的过程会导致构建再生成的困难。这在没有充分地编制过程文档的情况下特别突出，所以关于那些过程的知识仅掌握在一个或一些人手里。在分开的构建的情况下挑选每件东西效率非常低。构建结果很难解释，而且要花大量时间找出错误。
同样，脚本驱动的构建管理系统不能最优地利用构建服务器资源，因为，经常发生的活动是硬编码的，以运行在具体的系统之上。同样，硬编码的脚本令过程更加难于改变，因此，可以将工作共享，或在分布式团队中重新分配。如果知道“如何运行构建系统”的团队重要成员离开了项目，那么项目风险将会大大增加。
开源的局限性
这么多开发组织依赖自制的、脚本驱动的构建管理过程的理由不是不存在将构建管理自动化的工具 —— 而是这些工具不提供足够的可扩缩性。例如，许多开源的构建管理工具对小型项目很有效，这是他们设计的目标。举例来说，对比分布的，多服务器的环境，他们一般适合单服务器。
那些已经试图将这些工具的使用扩大到致力于多个项目的大型、分布团队的组织发现它们总是在缺少一些方面，像过程控制、连接性和自动文档化支持。为了企业开发环境而定制并维护这些系统所需的工作常常是很多的。（我个人觉得，一个企业开发团队为了试图使开源工具更加可伸缩得安排五个开发人员来重新构建这些工具。）这些活动增加了团队必须执行的手工工作，并且占用了开发人员致力于关键业务的宝贵时间。最后，许多组织发现了局限性，大多数现成的构建管理工具最多将它们置于等同于自己动手的系统之上。
效率的障碍
缺乏适当的工具已经证明是大型团队采用更有效的实践的绊脚石。要演进成有效的产品交付组织，您需要扩展您的企业的支持技术。类似的，您需要可审查的、可重复的、可靠的，您能够编码并在一个接一个项目中复用的过程自动化。为每个任务制作（并重新制作）您自己的工具所需的资源的消耗通常太大了。如果这样的组织可以找到可接受的第三方工具来替代构建并维护定制软件的话，那么成本和时间就会更有效了。
结构化方法的好处
更快速地创建更高质量软件中的长期难题是需要平衡速度和效率（特别是在开发的情况下，创造性），使用一致、可靠的 —— 也就是，结构化的 —— 方法。
不论团队的任务是开发、测试，或代码控制，它们都不希望在如何操作上受到约束，特别是在工具的选择上。他们的规程中的效率是极为重要的。 然而，从组织总体的更广泛的角度来看，优化效率可能需要一些额外的结构。
例如，拿法规遵循的问题来说。像金融服务和卫生保健行业中的许多商家都承受着重大压力，他们需要将在生命周期活动之内或跨生命周期活动如何行事，像开发软件，编制成文档。编制文档占用时间，并需要交流，可能降低效率。但是制裁的风险对整个公司来说是重要的。您的团队能够生成准确描述该团队如何构建一个一年前发布的产品的文档吗？该团队可以在法规遵循审查过程中重新生成该产品吗？同样，该团队能够重新生成构建或发布环境（操作系统、库，服务器内存配置，等等）吗？
理想情况下，您想要刚好够用的结构来直接处理像这样的问题，但仍旧可以灵活地选择在每个单个开发规程中使用最新和最好的的工具。这将是令开发团队更快地交付软件的一种方法，同时也令开发过程 —— 而且特别是构建过程 —— 更加可靠、一致，且可重复。
刚好够用的结构
要知道构建管理系统中“刚好够用的结构”的含义的一个方法是后退一步，确定优化构建和发布活动的质量和效率所需的跨规程的能力，不管每个规程是如何完成其特定的任务的。
将一个可伸缩的、有效的构建及发布管理基础架构看作是现代的州际高速公路，将软件开发规程看作是高速公路上的汽车。不论您开的是什么种类的车，跑车或小型货车，高速公路都有效地工作，在这种意义上说，它让您到达您需要去的地方。如果您拥有较快的车，那么您就更快地到达那里，但以哪种方式，基础结构都支持您，并且它不规定您选择驾驶哪种车。
同样，不论您使用什么工具，您希望跨过程的结果是一致的。让我们来看看，一个健壮、结构化的构建过程是如何帮助提供一致性的。
获得可见性
也许您从一个可伸缩的、跨规程的构建管理过程获得关键能力是跨开发活动的更好的可见性。这是极其有价值的，因为当有东西失败时，您可以更快速地看到发生了什么。举例来说，如果一个构建总是在特定点失败，那么您可以很容易地确定需要从哪个规程找原因了，因为您的过程是一致的，且定义良好的。那么您可以深入到问题出现的区域，并且快速地将其查出来。
缺少了适当的工具，这种水平的对问题自动的可视能力基本上是不可能的。相反，您需要召集一个有来自每个规程的代表参加的会议，试图弄清谁是做什么的，然后从那里开始推断对问题的解决方案...，退一步说，不是非常高效的。
改善沟通
您从一个可伸缩的、跨规程的构建管理过程获得的另一个关键能力是构建产品过程中所涉及的团队功能之间的沟通的改善。现今，大多数构建过程中，存在相当多手工沟通。例如，当开发人员检入代码时，她也许需要发一个电子邮件给构建工程师或其他人来开始一个构建过程。如果构建工程师早些时候离开去看牙医了，那么构建可能直到第二天早晨才能进行。这些种类的手工控制都减少了最终质量，并且增加了投放市场的时间。
手工构建过程中需要出现的所有各种各样的沟通点 —— 与开发、源控制、构建、测试、打包和部署相关 —— 生成了许多会延迟发布的潜在的缺口和时间槽。并且随着发布的推迟，将会削减特性，有时候削减测试 —— 为了满足交付日期，什么事情都有可能发生，而许多都给项目增加了风险，并且消极地影响了质量。
