| UML软件工程组织 | |||
| |
|||
|
|||
对于企业质量管理和构建驱动敏捷性的自动化构建管理
作者：Carey Benge 出处：IBM
本文来自于 Rational Edge：构建管理通常是横跨多个软件开发规程，并且是易于出错的，通过大规模的手工过程来执行。本文探究将关于大规模项目的构建管理活动自动化的方法，然后介绍 IBM Rational Build Forge 的自动构建及发布管理技术，以及改进的软件质量技术。 对于希望在整个软件开发生命周期中高质量且有效地构建软件的组织来说，构建管理的领域是在最后的边界之间。将软件系统的所有部分装配成可部署的、可使用的产品的过程需要许多步骤，并且涉及多个规程，包括开发、配置管理、测试和发布管理。虽然那些规程中的活动可能自动化程度很高，但是它们之间常常没有相互作用。 在较小的项目中，这种缺乏跨规程的自动化可能不是使人虚弱的问题。但是当应用变得越来越复杂、跨平台，并且是面向服务的，以及当团队越来越大，并且是地理上分散的时候，当今简陋的、且大量手工构建的过程开始被取缔了，构建并测试产品的任务越来越不可预测，并且很难重复。成本和进度上的风险可以达到无法接受的水平。 大家公认的是，开发团队经常花费大量时间来诊断构建过程中突然出现的错误 —— 有时候，比分离出错误的原因后对代码进行修整所花费的时间还长。同样，团队经常花费过多的时间来维护并过分小心地对待他们的脚本驱动的构建系统。这种级别的人工干涉不可避免地妨碍团队的生产力，并降低产品质量。问题是：对于这种情况能做些什么？ 在本文中，我将着眼于现今的构建管理过程经常怎样工作，并且探究在企业范围内的开发工作中有效地将该过程自动化的几种方法。最后，我将讨论用于将任何大小的环境中的构建及发布管理自动化的 IBM® Rational® Build Forge™ 的重要能力。 更大、更好、更快、更多遇到逐步上升的行业趋势的冲突时，开发组织需要满足似乎互斥的目标：即使是在软件产品和软件开发环境都更加快速地复杂化的情况下，还要增加产品质量，并加速向市场投放。 许多推动因素增加了这些困难，关键的是：
由于这些和其他因素，开发团队必须更加有效率、更加敏捷，并且更面向质量。这意味着提高软件开发生命周期中过程自动化和集成的效率及有效性是不可避免的。越来越多的组织为了自动化而瞄准的领域是构建管理。 不难看出存在改进构建过程的一般需求。作为开发和发布管理规程之间的夹层，构建管理活动会因为现有工具集之间的裂缝而失败。 每个规程都包括，将所有事情都放在一次构建中（开发、配置管理、测试、发布管理，等等），用其首选的工具进行活动，并且经常进行成熟、结构良好的过程）。但缺少的是跨所有规程集成的质量。这是成问题的，因为成熟的构建管理对整个团队效率是至关重要的。如果您不能足够频繁地“改变不稳定的构建”，那么开发和测试都将遭受痛苦。 类似 IBM Rational Unified Process®（RUP®）的方法为跨规程的开发活动的协调提供了最佳实践指导，但直到现在，也几乎不存在可以帮助让该指导应用于企业范围的解决方案。 典型的构建管理缺点许多构建管理系统本质上都是自制的，并且已经随着时间演进了。团队经常通过构建脚本来将它们的构建及发布过程自动化，然而，这些脚本驱动的系统很少适用于表现出现代软件开发特点的日益大型、复杂，且分布式的环境。常常每个任务都独立地运作，因此需要嵌入等待时间，并且适当地协调 —— 通常是手动地。在这种场景中，一个每夜都崩溃的构建可以很容易地说明，QA 人员只能在第二天闲坐着，失去了宝贵的测试时间，而开发和构建团队却在寻找错误故障。 当一个功能将可交付产品传给其他功能时，经常出现错误的大的空白。每个规程中的团队成员，通常都进行一些相对于其他规程来说有点自主的操作，在这种意义上来说，他们关注自己的核心能力，而不是他们的工作与整个产品构建过程之间的连接。因此，有时候当构建产品时，左手可能不知道右手在干什么。缺少一致、可重复的过程会导致构建再生成的困难。这在没有充分地编制过程文档的情况下特别突出，所以关于那些过程的知识仅掌握在一个或一些人手里。在分开的构建的情况下挑选每件东西效率非常低。构建结果很难解释，而且要花大量时间找出错误。 同样，脚本驱动的构建管理系统不能最优地利用构建服务器资源，因为，经常发生的活动是硬编码的，以运行在具体的系统之上。同样，硬编码的脚本令过程更加难于改变，因此，可以将工作共享，或在分布式团队中重新分配。如果知道“如何运行构建系统”的团队重要成员离开了项目，那么项目风险将会大大增加。 开源的局限性这么多开发组织依赖自制的、脚本驱动的构建管理过程的理由不是不存在将构建管理自动化的工具 —— 而是这些工具不提供足够的可扩缩性。例如，许多开源的构建管理工具对小型项目很有效，这是他们设计的目标。举例来说，对比分布的，多服务器的环境，他们一般适合单服务器。 那些已经试图将这些工具的使用扩大到致力于多个项目的大型、分布团队的组织发现它们总是在缺少一些方面，像过程控制、连接性和自动文档化支持。为了企业开发环境而定制并维护这些系统所需的工作常常是很多的。（我个人觉得，一个企业开发团队为了试图使开源工具更加可伸缩得安排五个开发人员来重新构建这些工具。）这些活动增加了团队必须执行的手工工作，并且占用了开发人员致力于关键业务的宝贵时间。最后，许多组织发现了局限性，大多数现成的构建管理工具最多将它们置于等同于自己动手的系统之上。 缺乏适当的工具已经证明是大型团队采用更有效的实践的绊脚石。要演进成有效的产品交付组织，您需要扩展您的企业的支持技术。类似的，您需要可审查的、可重复的、可靠的，您能够编码并在一个接一个项目中复用的过程自动化。为每个任务制作（并重新制作）您自己的工具所需的资源的消耗通常太大了。如果这样的组织可以找到可接受的第三方工具来替代构建并维护定制软件的话，那么成本和时间就会更有效了。 结构化方法的好处更快速地创建更高质量软件中的长期难题是需要平衡速度和效率（特别是在开发的情况下，创造性），使用一致、可靠的 —— 也就是，结构化的 —— 方法。 不论团队的任务是开发、测试，或代码控制，它们都不希望在如何操作上受到约束，特别是在工具的选择上。他们的规程中的效率是极为重要的。 然而，从组织总体的更广泛的角度来看，优化效率可能需要一些额外的结构。 例如，拿法规遵循的问题来说。像金融服务和卫生保健行业中的许多商家都承受着重大压力，他们需要将在生命周期活动之内或跨生命周期活动如何行事，像开发软件，编制成文档。编制文档占用时间，并需要交流，可能降低效率。但是制裁的风险对整个公司来说是重要的。您的团队能够生成准确描述该团队如何构建一个一年前发布的产品的文档吗？该团队可以在法规遵循审查过程中重新生成该产品吗？同样，该团队能够重新生成构建或发布环境（操作系统、库，服务器内存配置，等等）吗？ 理想情况下，您想要刚好够用的结构来直接处理像这样的问题，但仍旧可以灵活地选择在每个单个开发规程中使用最新和最好的的工具。这将是令开发团队更快地交付软件的一种方法，同时也令开发过程 —— 而且特别是构建过程 —— 更加可靠、一致，且可重复。 刚好够用的结构要知道构建管理系统中“刚好够用的结构”的含义的一个方法是后退一步，确定优化构建和发布活动的质量和效率所需的跨规程的能力，不管每个规程是如何完成其特定的任务的。 将一个可伸缩的、有效的构建及发布管理基础架构看作是现代的州际高速公路，将软件开发规程看作是高速公路上的汽车。不论您开的是什么种类的车，跑车或小型货车，高速公路都有效地工作，在这种意义上说，它让您到达您需要去的地方。如果您拥有较快的车，那么您就更快地到达那里，但以哪种方式，基础结构都支持您，并且它不规定您选择驾驶哪种车。 同样，不论您使用什么工具，您希望跨过程的结果是一致的。让我们来看看，一个健壮、结构化的构建过程是如何帮助提供一致性的。 也许您从一个可伸缩的、跨规程的构建管理过程获得关键能力是跨开发活动的更好的可见性。这是极其有价值的，因为当有东西失败时，您可以更快速地看到发生了什么。举例来说，如果一个构建总是在特定点失败，那么您可以很容易地确定需要从哪个规程找原因了，因为您的过程是一致的，且定义良好的。那么您可以深入到问题出现的区域，并且快速地将其查出来。 缺少了适当的工具，这种水平的对问题自动的可视能力基本上是不可能的。相反，您需要召集一个有来自每个规程的代表参加的会议，试图弄清谁是做什么的，然后从那里开始推断对问题的解决方案...，退一步说，不是非常高效的。 您从一个可伸缩的、跨规程的构建管理过程获得的另一个关键能力是构建产品过程中所涉及的团队功能之间的沟通的改善。现今，大多数构建过程中，存在相当多手工沟通。例如，当开发人员检入代码时，她也许需要发一个电子邮件给构建工程师或其他人来开始一个构建过程。如果构建工程师早些时候离开去看牙医了，那么构建可能直到第二天早晨才能进行。这些种类的手工控制都减少了最终质量，并且增加了投放市场的时间。 手工构建过程中需要出现的所有各种各样的沟通点 —— 与开发、源控制、构建、测试、打包和部署相关 —— 生成了许多会延迟发布的潜在的缺口和时间槽。并且随着发布的推迟，将会削减特性，有时候削减测试 —— 为了满足交付日期，什么事情都有可能发生，而许多都给项目增加了风险，并且消极地影响了质量。 沟通的进一个层面就是文档。在自制的构建过程的情况下，每个规程中的团队成员可能会手工地创建许多很快过期的文档。跨项目的，自动的构建管理的优势是它从头到尾都跟踪并控制所有的构建及发布活动，因此，可以让这些活动自己文档化。这也是将构建过程结构化如何减少整个团队工作，不是增加，的另一个实例。 构建管理系统也应该可以通过自动化更加容易地指定并执行各种标准，为了让过程更可预测，您需要将一些东西标准化，这样过程中所涉及的所有功能区域就都知道它们了。 命名约定就是一个很好的实例。为了跨规程将活动自动化，您需要确保所涉及的领域（开发、配置管理、测试等等）遵守适当的命名标准，以便它们拥有公共的参考体系，用来跨特定领域确定并关联构建的输入和输出。 标准可适用的另一个领域是过程的最佳实践复用。从事于多个、复杂的项目（例如，SOA）的大型、分布的项目的开发组织从为构建管理规定特定最佳实践活动的能力上获得了惊人的收益。例如，您可能希望命令每个项目团队都以与法规遵循或内部治理目的相关的报告形式获得具体的构建或部署数据。当关键业务的活动自动化、文档化，并可以复用时，团队极可能遵循它们。与此同时，让团队复用最佳实践，而不是重新将时间再次花在不同的项目上，这将帮助您减少项目的启动时间，减少重复工作，并且增强效率和整个产品质量。 跨规程的安全性是良构的构建和发布管理过程的另一个优点。例如，特定的角色或人员可能得益于在开发生命周期的各种阶段访问正在构建的软件的不同元素，让我说，就是通过运行一些测试来检查一些代码的健全性。但他们可能不必要在那些阶段拥有或控制那些元素（例如，测试脚本或无论什么）。 能够以授权和控制的形式建立安全机制，超越每个功能的工具集，围绕构建或部署过程中的整成点，可以有益于质量和效率。这是可以使开发人员在不需要于周日下午叫上构建工程师就可以安全地运行构建的东西。恰当的控制帮助消除了开发过程中残余的大量废物和闲散，并且实际地增加了灵活性。 像安全性一样，状态信息是超越任一个规程的软件开发的另一个方面。当您正在为发布而工作时，对您来说，实时地确定项目状态有多容易？您是处于测试阶段还是打包阶段？构建通过了所有测试吗，只通过了一些测试，等等？当您不能自顶向下地观察您的过程时，回答这种问题将是复杂，且耗费时间的。企业级构建管理系统可以帮助较大的团队处理这种跨规程的问题。 量度是确定项目状态能力的一个方面。当项目中的所有人都在同一个建筑物中工作时，状态信息比较容易得到。但是当团队在地理上分散时，沟通尤其不足。您需要以某种方式跨分布的过程测量关键的量度，从而确定状态。 事实上，您真正需要的是从一个中央位置综合地观察所有的运作的开发活动，从那里您可以观察，并度量您需要知道的任何事情。您是否花费过多的时间来开发或测试呢，如果是，为什么？当适当的结构连接规程时，做出这些种类的判定就容易得多了。 同理，当不从高层次观察您的整个过程时，您真的不会一看就知道缺陷在哪里，更不用说如何解决了。有了适当的量度，您就可以分析随着时间发展的过程趋势，从而确定瓶颈，并且不断地改进您的过程。缺少了量度，您就不得不利用所谓的“宗族的知识”、口述的意见、许多电子邮件，等等，手工地推断出那些判断。 重新定义敏捷开发您会发现关于什么构成了“敏捷性”或“敏捷开发”的许多不同的看法 —— 但您找不到一个打算争论更快地向市场交付更高质量产品的工具和过程的开发经理。 越来越多的组织开始通过更频繁的代码集成，部署提高质量并减少缺陷数量的敏捷类型的实践。当开发人员更加频繁地集成代码时，它们会更快地发现问题，并且在向下传之前修正它们。不幸的是，除了小型开发团队，对于其余所有开发团队来说，敏捷的好处大部分都没用到，或者大部分受限于开发规程。开发团队可能更频繁地迭代，但缺少了包含适当结构和控制的自动支持，就不能同样地促进构建活动，并且测试活动等也不能。 将构建管理自动化是将敏捷引入较大团队的一种方法 —— 同时还扩展了它们的范围和价值。实际上，企业级构建自动化能够重新定义“敏捷”，因为它令敏捷驱动的效率收益，越过开发方法到构建、测试、打包，及部署方法。也就是说，虽然开发人员更频繁地集成代码，但是健壮的构建自动化令其他规程也同样这样做：更频繁地构建、更频繁地测试，等等。通过去除了构建或部署循环中的瓶颈，整个软件开发生命周期可以更高效地进行。 当您在开发过程上使用恰当种类的跨功能的结构时，您可以使它更有效。假定您在美国的构建管理团队，与印度的开发团队合作，该团队只是检入一些源代码。他们现在需要等待数小时，等您睡醒，然后构建吗？如果是这样，那就不是“敏捷”了。 当构建管理适当地自动化时，海外的团队可以登录您的构建系统，自己运行构建过程（不用您照顾着），获得结果，了解到他们所检入的代码是否工作，及时地解决各种问题，等等。当您回到工作中来的时候，您的同事可能在您没有发觉之前，已经经过了许多这样的迭代。 这里有一个真实世界的实例：在 IBM Rational Build Forge 客户的其中一个那里，一个非常大型且分布的开发组织从一周进行 18 次构建到每周进行 360 次构建，将较频繁的代码集成的质量和效率收益从开发人员传递到 QA 团队（现在可以更频繁地测试更多构建），并且跨整个软件开发生命周期。如今这才是“敏捷”。 为了说明健壮的构建管理可以令开发人员 —— 以及整个团队 —— 更高效的另一种方法，让我们来想象另一个典型的软件开发情景。开发人员在其本地的工作区中编码并编译。在某一时刻，每个开发人员都必须将他的或她的的代码检入到源控制系统中，以考察这些代码是否能和其他人编写并提交的代码一起工作。常常，在本地工作区可以工作的代码在构建时刻就出现失败（或者破坏其他代码）—— 这是大多数项目每天延迟的原因。 团队倾向于这样工作的一部分原因是传统上开发和配置管理之间有一堵墙，因为这些功能本质上重视不同的东西：分别是速度与过程控制。开发人员抵抗着对他们的工具和过程的约束，因此，不论是谁管理源代码都需要让开发人员与之保持安全距离。 相反，如果您可以安全地让开发人员在构建管理的范围内工作，而不需要在任何人的部分上对速度、灵活性，或过程控制进行妥协，该怎么办？设想在不检入代码的情况下，您的开发人员是否可以通过在本地的工作区之外运行个人的“集成构建”来预检查代码。 考虑一下，如果开发人员可以从单元测试到进一步的测试，并且在正式的构建过程之外验证其新的代码，而不涉及其他开发人员的新代码的话，那么有多少要出现的缺陷不会出现在构建中，并且因此能够多通过多少次构建。想想开发人员会多频繁且多有信心地检入他们的代码 —— 从而进一步提高了整个团队的效率。 这些是对于自动构建管理带到现实中的“开发人员自服务”和“连续集成”的构想的重要方面。这种更高层次的效率和控制使所有开发规程更频繁地迭代，并且全面提高了生产力和质量。 IBM Rational Build ForgeIBM Rational Build Forge 提供了满足大型开发团队需求的自动的构建管理和软件交付过程。Build Forge 减少了规程之间重要集成点处的手工活动，同时自动地获取法规遵循、治理，或项目管理目的的相关数据。 Build Forge 提供的关键特性：
Rational Build Forge 使团队更快地、更频繁地，并且具有更大信心地生成构建，因而促进了整个开发工作，并且支持质量管理计划。 结束语虽然许多软件开发规程（源控制、缺陷跟踪、测试等等）愿意进行成熟、健壮的自动化，但是企业团队将构建和发布管理过程自动化的能力只是最近才出现的。同时，促进像 SOA 这样的趋势、增大法规遵从的风险，以及分布开发普遍性的增加，都对现今自制的构建或部署系统施加了巨大的压力。 不能够生成一致、准确，且可重复的软件构建已经成为约束质量和效率的主要控制因素。特别地，竖井式的以规程为中心的构建过程使跨软件生命周期的消息共享十分困难，并且导致不必要的错误、令人沮丧的延迟，以及成本和进度风险的增加。 软件开发生命周期中的最佳实践和过程改进已经成为 IBM Rational 的核心能力。我们在 Rational Build Forge 中提供的可伸缩的构建管理基础架构可以扩展跨整个软件开发生命周期的质量管理，与此同时，提高团队效率和生产力。去除了手工协调控制，并且改进了对项目状态的可视化的更加健壮的构建或发布过程意味着，花费更少的时间来从失败中恢复，并且在错误影响构建并延迟测试之前，提前查明并解决错误上升趋势的能力提高了。 随着企业团队获得构建和发布自动化的经验，例如，Build Forge 所提供的，它们可能希望进一步进行由压缩了的开发进度，和利用来自构建系统的长期数据将活动流水化、改进计划，并简化法规遵循和内部治理的能力所推动的过程改进。组织还可以通过增强以及时的方式，在一致的基础上提供高质量软件的能力来加强它们的客户关系。 所有这些过程改进都导致了软件质量管理的能力的提高，产生了最佳的投资效率、最佳的时间与价值比，以及客户满意度的提高。对于许多中型到大型的开发团队，或者分布团队来说，问题不是您是否要实现可伸缩的构建管理自动化，而是什么时候实现它们。 现在对本文进行讨论！尊敬的读者：现在有了一个特别为 Rational Edge 的文章创办的 新论坛，现在您就可以分享您对本文或本期杂志或以前杂志中的其他文章的想法。阅读世界各地您的同行们所说的内容，生成您自己的讨论，或者加入正在进行的讨论。单击 此处开始。 参考资料
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
