| UML软件工程组织 | |||
| |
|||
|
|||
大型组织的敏捷配置管理
作者：Peter Schuh 来源：IBM
本文来自于 Rational Edge：由于其规模及复杂性，大企业更需要拥抱敏捷开发策略。通过本文了解如何通过敏捷配置管理环境来有效地协调成百上千的资源。 在我作为顾问的早期，很幸运我有机会接触一个使用了被称为极限编程（eXtreme Programming）方法的项目。这个项目的环境十分典型：二十个人，有限的复杂度与平台需求。最后这个项目成功了。新方法帮助我们按时交付并且降低了缺陷。之后，我又经历了各种更具挑战性的敏捷环境，包括很大的项目团队（一百多人）和固定的成本花销。一种最普遍的方案就是他们全部是单一的项目团队，即使有些团队的规模很大。尽管具备了这些经验，我仍然不满意于敏捷开发为企业带来的好处 -- 尤其是关于配置管理的敏捷实践和技术 -- 直到我在两年时间内与财富 100 企业的项目团队一起工作后才发生了改变。 当我作为一名顾问进入到公司后，我发现这是一家不使用常规源代码控制、只有少量自动化构建或自动化单元测试的企业。我们花费了几个月的时间，利用持续的集成、短迭代、和各种其他的敏捷实践与技术，最终建立了一个更灵活的项目团队。当项目成功后，团队成员就可以帮助其他团队使用敏捷方法了。十八个月后，我们已经有了六个遵循主要敏捷配置管理实践的项目。每个项目团队具备自己的代码库，但是他们会互相共享组件、测试和构建流程。程序员会在一天内多次检入代码，尽快地增加自动测试，甚至写了几行代码后就会重新编译。项目团队会在一天内多次运行他们自己的自动化测试组件和系统。企业开始从更健壮的代码库、更及时的交付、和更好的最终产品中获益。 从那时起，许多大公司的开发团队都希望了解敏捷是否适合他们。他们一直认为敏捷是无序的、混乱的，并且风险很大。没有什么比事实更有说服力了。我自己的经验证明了敏捷实践和技术能够提供可靠的灵活的配置管理环境，而这正符合了大公司保持竞争力，满足质量的目标。 我将在本文中展示部分基本的敏捷配置管理构建模块，并详细介绍如何使用这些实践为大型开发企业带来收益。 开始之前：术语声明术语对于专业的软件开发来说既有益处又有坏处。也就是说，我们都利用术语来工作。不幸的是，我们往往使用它们的意思而使工作做得很糟糕。因此，在继续之前，我想首先花一些时间声明一下我将使用的术语。 由最先出现的开始 大型开发组织 可以有很多种形式。例如，它可以是一个大型项目，包括了上百人，为了计划和开发的目的分解为许多个子系统和子团队。它还可以是一家开发企业，包括许多相互联系的系统和项目团队。更一般的说法是，它可以是任何被描述为 "企业"的开发组织。 大的开发组织意味着多个团队和大量代码行。这些大型组织常常拥有不同阶段的开发、产品，或接近退役的系统；任意的数据库、文件仓库和其他的数据源；一系列不同的项目方案和委托；含有各种需求和议程的一群有趣的团队。这些大型组织常常接近（或已经陷于)复杂性之中。 更高水平的， 敏捷开发 很容易定义。它描述了任意的坚持敏捷软件开发的宣称价值的开发方法（尤其是伪装成项目团队熟知的方法论）。 1 简短来说，这些值关注于个人和交互、工作软件和用户协作，它们承认改变是不可避免的甚至是有价值的软件开发部分。但是这一高级定义仅描述了敏捷团队的价值，而没有他们所做的内容。当我谈论敏捷所做的内容时，我是指敏捷团队尊循的实践和技术，诸如持续集成、自动化的单元测试和短叠代。敏捷社区中不断讨论着遵循敏捷实践却不使用敏捷值的团队是否能够被称为敏捷的。这些值是十分重要的，因为它们提供了适当的 Agie 实践和技术的实现指导。但是，我将会跨过这些争论，使用术语敏捷以鉴别敏捷团队使用的实践和技术。 然后， 配置管理 -- 可被描述为 "质量"的概念 -- 传统意义上具有多种不同定义。 2 大家似乎完全同意配置管理包括了鉴别系统条目和特定条目与系统的变化。一种狭义的配置管理的定义可以满足流行源代码控制系统的实现及使用。同时， 一种广义的定义也许涵盖了全部项目团队和所有工件，包括全部的确保系统正确操作的代码和行为，所有改变控件行为，和追踪团队每天的变化。我将在本文中对配置管理采用一种中立的定义，包括了程序员所做的组织系统组件，了解任意时刻的系统状态、管理演化、确保开发过程中正确的系统功能。 大企业对敏捷实践的需求现在我们已经符合了讨论的标准，让我们看看它们是如何在一起工作的。首先，小型项目没有了质量不一和不正规的配置管理实践时，大部分读者可能都会同意大型开发组织都会需要正规的配置管理方法。这种认识在六年前被认为是十分大胆的，而我根据针对大型开发遇到的问题所做的观察得出的这一结论。当几十种（没有上百）产品组件正在运行，并且您与上百个（没有上千）开发者协作时，潜在的混乱、迟缓的开发周期、和很差产品质量的可能性是十分高的。大型系统变得过于复杂与迅速以至于不能靠手动系统加以维护了。因此在这些企业中，自动化、流程控制、管理变化、和团队协调对于保证开发质量是十分必要的。 其次，让我们讨论一下敏捷开发和配置管理的混合。当敏捷开发还是一种新兴的，软件开发专家最为重视的破坏进度、开销溢出、项目失败特点的主题时，没有人谈论配置管理的敏捷方法。但是敏捷证明了它是一种极好的配置管理实践，因为敏捷团队需要健壮的灵活的代码库以响应不断变化的业务环境和客户需求。一种方式是在项目中经常性的集成代码（一般来所，一天集成几次）。另一种敏捷的重要原则就是将测试作为一种有效的配置管理组件。在许多敏捷团队中，全部新代码都要经过自动化的单元测试，每次执行架构都会运行所有单元测试。未通过的单元测试将被视为与编译错误一样严重的问题。在任何好的配置管理流程中，敏捷团队都需要了解所有代码行的健康度。而且，他们努力保持对代码状态的控制。 最后，就是敏捷开发和大型开发组织。所有的大企业确实可从集成的敏捷开发部分获得收益。理所当然,有独特的大型开发组织的挑战，例如，与多个项目、系统、数据源连接的逻辑行为外的个人与团队间的通信与协作。但是无论是否遵循敏捷方法，大型组织都有其需要面对的问题。 敏捷开发能为大型企业提供什么？首先，敏捷能够通过自动化的实现任务以减少人类所犯错误并使得团队利用更少的资源作更多工作以提高团队效率。其次，敏捷能够帮助大型企业改进质量，更有效的处理回馈给开发成员的改变，从而更迅速的解决问题。第三，敏捷能够通过使用叠代计划、分析、开发行为 -- 这些可由系统根据所设计的代码自动化的产生 -- 替换庞大的（且很快过期的）需求文档，以进行更丰富更及时地沟通。 最后，敏捷配置管理方法可以在项目级或企业级加以实现。不需要在这之前考虑一个组织，因为单个项目可以是一种实验性的或想法孵化器。同时，当在企业级实现了敏捷配置管理实践，那么企业必须为每个项目团队提供足够的灵活性与自主性，实现其最佳解决方案。 敏捷配置管理实践精简进程和自动化是敏捷配置管理方法的基础。 3 每一个活动（来自于代码检测确定损坏测试）都应很容易的执行，并为单个程序员和整体团队提供快速反馈。而且，敏捷团队力图使得这一行为自动化的记录于文档中。例如，自动化的构建仅需要写入它的执行脚本中。可以很容易的得出包括由 Microsoft Word 所创建的过期文档，"指南"文档在内的良好自动化构建脚本收集的好处。 已根据各种项目环境中的用途标识出了组成敏捷配置管理的实践 -- 无论大或小，简单或复杂。 我将在本部分中探讨实践，下一部分讨论针对大型企业特殊需求的应用。 这是常常会忘记的重要敏捷配置管理的组件，并不是因为组成敏捷团队不使用源代码控制。它常常被忘记是因为大部分敏捷团队假定每个项目都会有一个源代码控制系统，并且每个项目都会正确的使用它。一般的源代码控制系统都会有许多部分，例如版本化、回滚、打标签以及合并等。但是更重要的是，源代码控制为全部项目团队或开发组织的代码行提供了可靠的记录位置 。这仅仅当每名程序员能够经常性的检入系统代码时才会发生。我的意思是至少一天一次。这时，项目能够了解在哪里找到当前系统。它不会由于不同的开发工作站，或位于不同地点的共享服务器造成支离破碎。当前系统（或仅仅几小时前）总是检查源代码控制系统。 重申一下，仅仅因为项目或组织具有源代码控制系统不意味着系统支持敏捷配置管理方法。在我管理几个团队的客户端，两百名员工的开发组织使用企业级的源代码控制授权工具。但是系统却有重大的瑕疵：执行一次 check-in 要花费数小时！因此，团队仅仅在不得已的时候才做一次 check in -- 在发布到产品环境之前。一种普通的源代码控制系统对于一家大型企业十分有益（之后会做解释），但是仅仅限于程序员和团队能够以具有时效的方式检入/检出代码的情况。 我将对源代码控制作最后的解释。团队不应该仅仅对所写代码进行版本控制；还必须对编译与测试代码的流程（或脚本）进行版本控制。如果团队需要先前的代码，那么就可以回溯到所需的构建和测试流程。 自动化构建是团队用以评估当前软件或系统稳定性的第一步。而且，自动化的构建还可以降低程序花费在不必要任务上的时间，并且减少了来自开发流程的瓶颈（也就是，团队依靠于一个构建人员或一个独立的构建团队），从而实现了对于改变的更迅速的响应。 这一实践的目的是将构建流程简化为一个任何程序员都可以执行的点击一个按钮的 行为。这一行为应该包括相关系统的全部代码，不论程序员工作于什么组件或接口上。同时，系统必须能够快速编译。更快的工作站、增加的编辑和可选择的编译器可以使得编译时间更加短暂。对于程序员来说，写新代码的同时快速构建系统的能力具有许多好处。首先，它帮助程序员验证编码时设想的正确性 -- 例如，检验一个外部 API 是否如设想似的工作。其次，规则化的代码构建可以预防问题的发生。最后，它能够识别未知的很少通过本地构建显现的"远离"系统部分依赖关系。 自动化的构建将会减少团队编辑和收集问题的时间。程序员不再需要等待数小时或者执行一组费劲的任务以确信新写的代码能够编译。取而代之的是，在程序员编写代码后不久，他就能够知道是否新代码与旧有代码集成到了一起。这表示编译与集成错误将会变得显而易见，且处理起来更迅速更容易。 最后，自动化的构建对于更大系统更加重要。 大项目会继承或连接大量其它平台的系统，尤其是需要考虑有意义的联合构建流程的实际策略。在这种环境中要想获得较短的编译时间是极具挑战性的。文章的后面我将会探讨一些处理大系统构建的方法 -- 就是说，对于一个团队来说，编译与测试完整的系统并不是现实的。 这是在自动构建之后的步骤。自动化的移植与部署行为的原因是为了精简与增强来自测试环境开发与生产环境的构建提升的可预见性。大量的问题往往来自首次引入系统测试、用户验收测试、在生产环境摸索的项目。在自动化移植中，团队可以将代码转入干净的"生产级" 环境，在那里可以执行自动化的单元和系统级测试。通过在接近生产环境下测试，团队可以在系统测试前识别出环境、集成和性能方面的问题。这样可使得团队更加熟悉实际的产品部署流程。最后，当自动化的实现了主要的产品部署流程时，就可以从公式中去除了人所犯的错误。 另一个移植与部署的重点是这些行为由一个专职团队负责管理。将这些流程集成入项目团对每日的行为中能够为各个团队带来有效及时地平衡。无可否认的是，对于大型企业来说这是极具挑战性的，因为他们的规模、报告结构和多重地理范围的因素。下面我将会更深入的探讨这一问题的解决方案。 自动化的测试是了解当前系统是否达到准备发布状态的第一步。自动化测试应伴随系统中的全部新代码。除此之外，当老的、未测试的代码被改变的时候，程序员应为代码编写新的测试。最后，当在验收测试或产品中发现缺陷时，应记录这一测试以证明缺陷，并且这一新测试应加入到全部测试集合中以避免今后发生相同的问题。当系统中所有的单元测试全部通过后，程序员应当对其代码有信心，相信不会影响系统的其他部分。 从敏捷的观点来看，自动化的单元级测试是构建流程的扩展。程序员每次运行构建流程并成功编译代码时，应遵循所有的应用单元测试。在敏捷配置管理环境中，损坏的单元测试与损坏的构建严重程度是一样的。这样小问题就不会扩展为大问题了。大问题（诸如全部程序停止工作）不会隐藏在后台。取而代之的是，团队可以在问题发生时定位，不断增长的单元测试集增加了准确监测错误的可能性。 我要补充一点关于单元级和系统级测试的内容：明智的项目和企业会进行 测试数据管理。这样就使得测试数据很容易的创建、修改、维护（当系统数据结构发展变化时）、存储（在每次测试前）。当数据模型发生大的变化时，甚至是在某些情况下，当开发数据库被清理掉时，依赖于脆弱的以及被随意修改的数据结构的大量自动化测试集就可以得到迅速的调整。 持续集成与源代码控制、自动化构建流程、值得信赖的自动化测试集共同保证了开发过程中系统的稳定性和系统性能。在持续集成的环境中，程序员需要编写代码，在工作站上运行构建和测试，一天内多次进行检入。同时，有一台构建机（或一组机器）用以编译整个系统，在类似于产品配置的干净的环境中运行所有测试。这种行为可通过手动或者自动的方式启动 -- 或者间隔固定的时间或者由程序员检查代码。当代码没有在干净的环境中通过构建和测试时，无论什么原因，都会在检查后提醒全体成员。大部分情况下，敏捷团队都不会允许任何人检入额外的代码，直到解决了问题。 持续集成带来的好处是，它灌输了一种开发原则，不鼓励检入低质量的代码，且当问题发生时需要立刻解决。由于每天要进行多次代码检入 ，处于集成环境中的程序员很少或从不改变引起不稳定构建的代码。除此之外，如果遇到未完成的代码，团队的构建机制能够在几小时内记录它，而不是几天或几周。因此，程序员在中断代码前，不得不仔细考虑整体设计，甚至需要进行一些测试。这意味着处于持续集成环境中的程序员很少会在系统代码中直接进行试验，很少出现写了一半却忘记完成的函数，或是将系统组件遗忘在某处。当编写代码后立即监测出错误，解决问题所花费的时间往往少于几天或几周后才发现时所花费的时间。 这样，就保证了高质量的代码和更加迅速的发行周期。 对于大系统的可扩展的敏捷配置管理大型企业经历过许多类似中小型项目遇到过的 CM 问题，还有部分附加的多系统、多项目、多初始属性的问题。例如，当小项目未监测出一个缺陷或者遇到了需要花费几个小时甚至几天才能解决的集成问题时，对于大型企业来说也许会花费几周的时间才能解决。相似的还有，对于小项目的源代码控制和版本的问题相比较于大型企业没有可依赖的配置管理系统时所遇到的系统回滚或多应用重新部署问题来说，简直是微不足道的。依据其规模与复杂度来说，适当的配置管理实践对于大企业是十分必要的。 配置管理的敏捷方法能够帮助大企业定位配置管理问题，同时保持对客户需求变化、进化的业务环境、不断提高的技术的灵活性。除此之外，敏捷配置管理方法还能够帮助新项目重复使用现有系统与项目的构建流程加快构建与运行的脚步。 本部分中，我们将会探讨在大型开发组织中使用敏捷实践的三个主题。第一，我们将探讨如何灵活的执行敏捷的 CM 流程为单个项目团队和大型开发组织带来好处。第二，如何在地点分散的企业中的分布式项目上使用敏捷配置管理方法。最后，企业如何通过深思熟虑的应用与流程集成加速软件交付周期，增强规模经济。 每天的项目环境中往往需要团队间共享代码，使用通用库，甚至共享一个又一个的构建流程。例如，一个项目也许需要包含其它项目的构建与测试行为。这可能包括获得共享库的更新版本以确保其它项目的改变不会影响团队的代码，或是保证团队代码库德变化不会影响另一个项目代码的功能。而且，项目间可以共享随时更新的核心资源。这种资源可以包括通用类或类似于测试工具与测试数据生成器等。这种情况在大型企业中十分普遍，它们会自然而然的形成，不需要企业自身的协调。 敏捷方法为开发团队提供了更有效合作、实时通信以保证项目进展的机会。通过提供构建成功/失败的快速反馈，开发者能够在最恰当的时候检测与解决问题。 为了在大型开发组织中更加有效，敏捷实践必须在单个团队级别上实现，但是应由企业级配置管理最佳实践支持。当执行企业级敏捷配置管理方法时，团队必须负责起多项任务。第一，必须允许基于实践的可靠的敏捷配置管理执行。第二，必须使得流程对于其他团队可见。第三，适当的时候必须包括自身构建与测试行为的系统构建流程。最后一步不需要程序员在每天的工作中完成，但它必须由一个自动化流程尽可能多的执行（理想情况下，从一天一次到一周一次之间）。当其他系统出现问题时，必须快速解决。 为帮助所有团队执行敏捷配置管理， CM 组织还将负有不同的责任。这些任务属于共享的服务实体（常常被称为 Engineering Services Groups)。这种企业会提供一个通用的、用户友好的工具集获平台，所有团队可通过它们完成与共享源代码控制、构建、和测试行为。这种平台包括诸如源代码控制、构建、和测试系统的组件。而且，企业应在 敏捷配置管理实践的执行中提供支持与引导，提供一组可重复使用的 CM 流程或最佳实践推荐以实现一致性和可靠性。最后，企业必须确保每个团队必须具有足够的 CM 流程控制的能力。这看起来有点像在搞平衡，但是对于有效的软件交付来说是有必要的。最终，仍然是团队构建软件，企业的工作是帮助每个项目获得最大的成功。 许多敏捷方法论确实没有考虑分布式团队的情况，但是这一大企业中的普遍特征不会被希望改变软件开发产业的进步所忽视。尽管缺乏具体的关注，但是敏捷配置管理方法仍然对于具有分布式团队环境的项目和企业来说十分有效。 为了从敏捷配置管理方法中获益，分布式的项目和企业必须平衡部分敏捷配置管理实践的固定实现，尤其是固定的源代码控制使用、持续集成、和自动化测试。我们不能夸大经常检入和稳定构建维护的重要性，因为被时区或地理位置分开的团队成员需要访问完成的可操作的系统版本。当某些部分损坏或过期后，没有其他位置的团队成员可以帮你一把。 为了给分布式项目维护敏捷配置管理解决方案，必须检查源代码控制，包括构建脚本和本地环境设置。在任何一个位置的改变都必须自动复制到其他的开发场所。这是因为分布式团队协作和大系统的复杂性决定的。一旦开发过程中系统仅在一处开始出现离奇的行为时，也许需要花费很长时间才能找到问题的根源，而这一问题仅仅是因为没人会想到引起如此问题的服务器或虚拟机的设置。 除此之外，与数据库相关的所有部分都需要被复制与共享。这可以通过定制所有数据库的改变和检验源代码控制实现。 4 它还可以通过某种数据库复制的形式实现。最后，项目必须解决连接或开发行为必须执行的第三方系统的问题。每处场所都必须具有访问相同系统的能力。 有两种普遍的实现分布式和敏捷配置管理环境的方法。第一种就是建立一个单一的开发环境，它可被所有开发团队连续访问。这种环境包括 -- 至少 -- 单一的源代码控制系统，全部数据库和连接系统，执行持续集成的能力。这种解决方案适合于工作在临近时区且具有可靠网络访问能力的团队。第二种方法是构建概念上的单机开发站点。每个团队具有一个完整独立且相同的开发环境，包括源控件，数据库，附加的系统安装，和持续集成安装。每天的复制计划必须保证所有站点的代码，数据，和环境的同步改变。同步行为必须尽可能的自动化。而且，自动化测试必须有规律的编写与执行。如果没有执行每天的复制和完整测试（就是说，如果没有同步化操作），企业也许不久会发现自身处于梦魇中。最后，项目和企业可以使用中立的解决方案，即部分敏捷配置管理环境集中实现，而剩余部分由各个站点单独实现。例如，企业具有通用的源代码控制和构建系统，但是在不同开发场所维护本地数据库实践和其他第三方系统。 如果在创建良好构建流程和自动化前进行了充分的考虑与准备，那么它会成为十分有用的开发资产，这些设施能够（应该）在多个项目间做到平衡。大企业的低效源自于为每个软件项目创建一个新的构建系统。结果是以专门的硬件资源和配置管理人员支持多个定制的构建程序。这样就使得大型企业不能根据规模效益从资源池、人员和最佳实践知识中获益。 如果企业计划在任意规模实现敏捷实践（意味着在多个团队、项目和/或操作平台上同时进行 编码-构建-测试-部署周期），那么应当仔细思考这些系统如何通信、交互以创建平滑的编码-构建-测试-部署周期。如果跨团队的，跨系统的整合不是全部开发策略的因素，那么团队常常会发现隔阂，等待周期，和函数间的错误通信会造成开发进度的迟缓。如果没有追踪和收集每个阶段信息的设施，那么团队很难确定系统真实的健康度和发布状态。 集成应包括来自核心开发系统的工作流自动化和信息共享（或者至少是抽取）。工作流自动化包括包括任务的次序与安排，并且应包括基于规则的改变任务执行与前步成功或失败告知的能力。当决定您的集成方法时，团队应考虑产业标准方法(XML，等)以构建适应需求改变和开发应用的灵活的解决方案。 如需浏览 IBM Rational Build Forge 如何在大型开发组织中快速实现敏捷方法，点击这里。 注释1您可以在http://www.Agilemanifesto.org 中找到敏捷声明。 2如果需要阅读详细资料的文章，请浏览 Bard Appleton on the CM Crossroads Wiki 所作的针对配置管理所收集的定义： http://www.cmcrossroads.com 3 本文调整了书中的部分内容，Integrating Agile Development in the Real World 更详细的描述了这些实践。 4 要想了解更多有关建立与管理数据库的信息，请阅读我的文章 "Agility and the Database." 它位于 http://www.peterschuh.com/articles.html 参考资料
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
