自动文档编制

    沟通的进一个层面就是文档。在自制的构建过程的情况下，每个规程中的团队成员可能会手工地创建许多很快过期的文档。跨项目的，自动的构建管理的优势是它从头到尾都跟踪并控制所有的构建及发布活动，因此，可以让这些活动自己文档化。这也是将构建过程结构化如何减少整个团队工作，不是增加，的另一个实例。

    增强标准

    构建管理系统也应该可以通过自动化更加容易地指定并执行各种标准，为了让过程更可预测，您需要将一些东西标准化，这样过程中所涉及的所有功能区域就都知道它们了。

    命名约定就是一个很好的实例。为了跨规程将活动自动化，您需要确保所涉及的领域（开发、配置管理、测试等等）遵守适当的命名标准，以便它们拥有公共的参考体系，用来跨特定领域确定并关联构建的输入和输出。

    标准可适用的另一个领域是过程的非常好的实践复用。从事于多个、复杂的项目（例如，SOA）的大型、分布的项目的开发组织从为构建管理规定特定非常好的实践活动的能力上获得了惊人的收益。例如，您可能希望命令每个项目团队都以与法规遵循或内部治理目的相关的报告形式获得具体的构建或部署数据。当关键业务的活动自动化、文档化，并可以复用时，团队极可能遵循它们。与此同时，让团队复用非常好的实践，而不是重新将时间再次花在不同的项目上，这将帮助您减少项目的启动时间，减少重复工作，并且增强效率和整个产品质量。

    提高构建安全性

    跨规程的安全性是良构的构建和发布管理过程的另一个优点。例如，特定的角色或人员可能得益于在开发生命周期的各种阶段访问正在构建的软件的不同元素，让我说，就是通过运行一些测试来检查一些代码的健全性。但他们可能不必要在那些阶段拥有或控制那些元素（例如，测试脚本或无论什么）。

    能够以授权和控制的形式建立安全机制，超越每个功能的工具集，围绕构建或部署过程中的整成点，可以有益于质量和效率。这是可以使开发人员在不需要于周日下午叫上构建工程师就可以安全地运行构建的东西。恰当的控制帮助消除了开发过程中残余的大量废物和闲散，并且实际地增加了灵活性。

    状态和量度

    像安全性一样，状态信息是超越任一个规程的软件开发的另一个方面。当您正在为发布而工作时，对您来说，实时地确定项目状态有多容易？您是处于测试阶段还是打包阶段？构建通过了所有测试吗，只通过了一些测试，等等？当您不能自顶向下地观察您的过程时，回答这种问题将是复杂，且耗费时间的。企业级构建管理系统可以帮助较大的团队处理这种跨规程的问题。

    量度是确定项目状态能力的一个方面。当项目中的所有人都在同一个建筑物中工作时，状态信息比较容易得到。但是当团队在地理上分散时，沟通尤其不足。您需要以某种方式跨分布的过程测量关键的量度，从而确定状态。

    事实上，您真正需要的是从一个中央位置综合地观察所有的运作的开发活动，从那里您可以观察，并度量您需要知道的任何事情。您是否花费过多的时间来开发或测试呢，如果是，为什么？当适当的结构连接规程时，做出这些种类的判定就容易得多了。
   
    同理，当不从高层次观察您的整个过程时，您真的不会一看就知道缺陷在哪里，更不用说如何解决了。有了适当的量度，您就可以分析随着时间发展的过程趋势，从而确定瓶颈，并且不断地改进您的过程。缺少了量度，您就不得不利用所谓的“宗族的知识”、口述的意见、许多电子邮件，等等，手工地推断出那些判断。

    重新定义敏捷开发

    您会发现关于什么构成了“敏捷性”或“敏捷开发”的许多不同的看法 —— 但您找不到一个打算争论更快地向市场交付更高质量产品的工具和过程的开发经理。

    越来越多的组织开始通过更频繁的代码集成，部署提高质量并减少缺陷数量的敏捷类型的实践。当开发人员更加频繁地集成代码时，它们会更快地发现问题，并且在向下传之前修正它们。不幸的是，除了小型开发团队，对于其余所有开发团队来说，敏捷的好处大部分都没用到，或者大部分受限于开发规程。开发团队可能更频繁地迭代，但缺少了包含适当结构和控制的自动支持，就不能同样地促进构建活动，并且测试活动等也不能。

    将构建管理自动化是将敏捷引入较大团队的一种方法 —— 同时还扩展了它们的范围和价值。实际上，企业级构建自动化能够重新定义“敏捷”，因为它令敏捷驱动的效率收益，越过开发方法到构建、测试、打包，及部署方法。也就是说，虽然开发人员更频繁地集成代码，但是健壮的构建自动化令其他规程也同样这样做：更频繁地构建、更频繁地测试，等等。通过去除了构建或部署循环中的瓶颈，整个软件开发生命周期可以更高效地进行。

    构建驱动的“敏捷性”

    当您在开发过程上使用恰当种类的跨功能的结构时，您可以使它更有效。假定您在美国的构建管理团队，与印度的开发团队合作，该团队只是检入一些源代码。他们现在需要等待数小时，等您睡醒，然后构建吗？如果是这样，那就不是“敏捷”了。

    当构建管理适当地自动化时，海外的团队可以登录您的构建系统，自己运行构建过程（不用您照顾着），获得结果，了解到他们所检入的代码是否工作，及时地解决各种问题，等等。当您回到工作中来的时候，您的同事可能在您没有发觉之前，已经经过了许多这样的迭代。

    这里有一个真实世界的实例：在 IBM Rational Build Forge 客户的其中一个那里，一个非常大型且分布的开发组织从一周进行 18 次构建到每周进行 360 次构建，将较频繁的代码集成的质量和效率收益从开发人员传递到 QA 团队（现在可以更频繁地测试更多构建），并且跨整个软件开发生命周期。如今这才是“敏捷”。

    开发人员自服务

    为了说明健壮的构建管理可以令开发人员 —— 以及整个团队 —— 更高效的另一种方法，让我们来想象另一个典型的软件开发情景。开发人员在其本地的工作区中编码并编译。在某一时刻，每个开发人员都必须将他的或她的的代码检入到源控制系统中，以考察这些代码是否能和其他人编写并提交的代码一起工作。常常，在本地工作区可以工作的代码在构建时刻就出现失败（或者破坏其他代码）—— 这是大多数项目每天延迟的原因。

    团队倾向于这样工作的一部分原因是传统上开发和配置管理之间有一堵墙，因为这些功能本质上重视不同的东西：分别是速度与过程控制。开发人员抵抗着对他们的工具和过程的约束，因此，不论是谁管理源代码都需要让开发人员与之保持安全距离。

    相反，如果您可以安全地让开发人员在构建管理的范围内工作，而不需要在任何人的部分上对速度、灵活性，或过程控制进行妥协，该怎么办？设想在不检入代码的情况下，您的开发人员是否可以通过在本地的工作区之外运行个人的“集成构建”来预检查代码。

    考虑一下，如果开发人员可以从单元测试到进一步的测试，并且在正式的构建过程之外验证其新的代码，而不涉及其他开发人员的新代码的话，那么有多少要出现的缺陷不会出现在构建中，并且因此能够多通过多少次构建。想想开发人员会多频繁且多有信心地检入他们的代码 —— 从而进一步提高了整个团队的效率。

    这些是对于自动构建管理带到现实中的“开发人员自服务”和“连续集成”的构想的重要方面。这种更高层次的效率和控制使所有开发规程更频繁地迭代，并且全面提高了生产力和质量。

    IBM Rational Build Forge

    IBM Rational Build Forge 提供了满足大型开发团队需求的自动的构建管理和软件交付过程。Build Forge 减少了规程之间重要集成点处的手工活动，同时自动地获取法规遵循、治理，或项目管理目的的相关数据。

    Build Forge 提供的关键特性：

    .用于集中管理竖井式的构建或发布过程的基于 Web 的控制台，以及简化的用户管理
    .自动地关联来自不同源控制、测试，及缺陷跟踪工具的数据，以在高层观察产品开发状态的能力
    .跨多个平台与现有的工具灵活地集成，因此个别规程不受非常好的解决方案选择的约束
    .支持线程，因此，您可以将构建分成可以同时运行的独立的过程，优化硬件利用和构建时间
    .为了更好地再现构建、更快地解决问题，简化法规遵循管理，并提高测试准确度而自动编制材料单（一系列内容和变更）
    .“非常好的实践过程”库，您可以在项目间复用，从而减少启动时间，提高可伸缩性，并增加效率和质量
    .随着重要过程的演进，自动对其进行文档编制 —— 为法规遵循管理提供过程变更的审计跟踪，使工作量的共享和转移更加容易，并且减少“人才流失”的风险，因为（晦涩难懂的）过程的详细知识对构建的管理不是必要的
    .开放的命令行界面让团队可以在过程之间创建“智能链接”，从而优化效率，并改进故障排查
    .开发人员自服务能力，例如，开发人员可以在检入代码之前，通过在基于 Eclipse 的 IDE 中按照需求安全地运行构建来进行预测试（也就是说，让代码“试运行”）
   
    Rational Build Forge 使团队更快地、更频繁地，并且具有更大信心地生成构建，因而促进了整个开发工作，并且支持质量管理计划。

    结束语

    虽然许多软件开发规程（源控制、缺陷跟踪、测试等等）愿意进行成熟、健壮的自动化，但是企业团队将构建和发布管理过程自动化的能力只是最近才出现的。同时，促进像 SOA 这样的趋势、增大法规遵从的风险，以及分布开发普遍性的增加，都对现今自制的构建或部署系统施加了巨大的压力。

    不能够生成一致、准确，且可重复的软件构建已经成为约束质量和效率的主要控制因素。特别地，竖井式的以规程为中心的构建过程使跨软件生命周期的消息共享十分困难，并且导致不必要的错误、令人沮丧的延迟，以及成本和进度风险的增加。

    软件开发生命周期中的非常好的实践和过程改进已经成为 IBM Rational 的核心能力。我们在 Rational Build Forge 中提供的可伸缩的构建管理基础架构可以扩展跨整个软件开发生命周期的质量管理，与此同时，提高团队效率和生产力。去除了手工协调控制，并且改进了对项目状态的可视化的更加健壮的构建或发布过程意味着，花费更少的时间来从失败中恢复，并且在错误影响构建并延迟测试之前，提前查明并解决错误上升趋势的能力提高了。

    随着企业团队获得构建和发布自动化的经验，例如，Build Forge 所提供的，它们可能希望进一步进行由压缩了的开发进度，和利用来自构建系统的长期数据将活动流水化、改进计划，并简化法规遵循和内部治理的能力所推动的过程改进。组织还可以通过增强以及时的方式，在一致的基础上提供高质量软件的能力来加强它们的客户关系。

    所有这些过程改进都导致了软件质量管理的能力的提高，产生了非常好的的投资效率、非常好的的时间与价值比，以及客户满意度的提高。对于许多中型到大型的开发团队，或者分布团队来说，问题不是您是否要实现可伸缩的构建管理自动化，而是什么时候实现它们。

    参考资料
 
    您可以参阅本文在 developerWorks 全球网站上的 英文原文。
    您可以参阅 Rational Edge 电子月刊中文版 的其他文章。
    IBM Rational Build Forge Web 页面
    IBM Rational 质量管理 Web 页面
    关于 Build Forge 的白皮书： Build Forge 白皮书
    Peter Schuh 最近的 developerWorks 文章关于：“大型组织的敏捷配置管理”。