敏捷软件开发中的配置管理探讨

陈申平

（中国电子科技集团公司第七研究所，广东 广州 510310）

0 引言

软件配置管理是采用配置识别、配置控制、配置状态记录及配置设计等手段，建立与维护工作产品完整性的一门学科[1]。配置管理侧重于严格地控制工作产品方面的管理和技术，包括产品的实现或服务。

2010年 11月，SEI正式发布了《CMMI for Development》1.3版，主要的变化就是增加了对敏捷方法的支持，并在项目策划、风险管理、质量保证等相关过程域中增加了敏捷方法的使用说明。全球使用敏捷方法的软件企业日益增多。2002年前后，敏捷方法开始被国内的软件人员所了解。作为敏捷方法在国内的先行者，中兴、华为、腾讯等民营企业已开始应用敏捷方法。近年来，越来越多的国企也开始采用敏捷方法，如银行、证券公司、通信研究所等。

敏捷软件开发中，为支持快速变更、快速建立、多重基线，个人、团队、甚至线程等多重配置管理工作空间，配置管理是非常重要的。软件配置管理不仅仅是控制和停止变更，它实际上提供了一个能服务和支持敏捷开发团队的完整技术范围和过程[2]。为实现配置管理活动更好地服务于敏捷软件开发，国内外许多学者对敏捷软件开发中的配置管理活动进行了研究[3-6]。

本文结合敏捷的特点，探讨了敏捷软件开发中如何使用配置管理来控制软件开发过程，以及软件配置管理技术如何支持和加强并行工作与持续集成两项敏捷活动，并描述配置管理在Scrum敏捷模型中的应用，为其他敏捷方法提供了参考依据。

1 配置管理介绍

1.1 配置管理定义

CMMI模型认为配置管理是一门学科，它应用技术的、管理的指导和监督以于[1]：

（1）识别和记录配置项功能特征和物理特征；

（2）控制这些特征的变更；

（3）记录和报告变更的处理和执行状态；

（4）验证其是否符合特定的需求。

1.2 配置管理活动

配置管理的目的是通过采用配置识别、配置控制、配置状态纪实和配置审核来建立和维护工作产品的完整性[2]。软件配置管理包含的活动如下[7]：

（1）制定配置管理计划；

（2）配置识别；

（3）配置变更控制；

（4）配置状态纪实；

（5）配置审核；

（6）发布管理和交付。

配置管理活动如图1所示：

图1 配置管理活动图[7]Fig.1 Configur ation management activity diagram[7]

2 敏捷软件开发中的配置管理活动

敏捷软件开发方法是一种以人为本、迭代、应对需求快速变化的一种“轻量型”软件开发方法。其主要特点是：迭代式开发、增量交付、持续集成、开发团队自我管理、开发团队与用户反馈推动产品开发[8]。本节描述了可添加到敏捷方法中的四项典型活动，以向团队提供更多帮助。同时介绍软件配置管理技术如何支持和加强并行工作与持续集成两项敏捷活动。

2.1 配置识别

对敏捷方法而言，配置识别最重要的部分是配置项识别和组成。对一个项目，一些产品是非常重要的，这些产品应识别为配置项，其它含有更多个人隐私的产品（如草图、经验、笔记等）不需要识别为配置项。尽管部分私人工作产品不是配置项，仍然需要保存和版本化。因此，在配置管理工具中，划分产品、配置项和非配置项的结构是非常重要的[9]。

敏捷软件开发中，每次迭代过程中需制定迭代计划、进行持续开发和测试。因此，敏捷配置管理较传统配置管理方法新增的配置项有测试代码、测试工具和测试脚本、持续集成相关工具、构建脚本、迭代计划、迭代任务列表、用户故事或用户卡[2]。

敏捷软件开发中，完整的工作产品需要多次迭代才能完成，因此，配置项与基线的建立时机与传统方法不同。每次迭代阶段应编写文档片段并测试实现的代码，当完整的文档通过评审或所有代码通过测试后，将文档或代码入软件受控库，并建立相应的基线。迭代过程中，可以在软件开发库建立迭代基线。敏捷软件开发中至少需要建立软件功能基线、软件分配基线、软件产品基线三条基线，基线及配置项如表1所示：

表1 敏捷软件开发中的基线及配置项表Tab.1 Baseline and configuration table for agile software development

2.2 配置控制

配置控制包括版本控制和变更控制，这里只介绍变更控制。配置管理变更请求的跟踪贯穿整个生命周期。在任何时间点，了解变更请求的当前状态和谁负责变更是非常重要的，这有利于处理变更请求和协调不同人员的工作[9]。

可追溯性是软件配置管理中一个非常重要的特性，是配置管理的目标之一。可追溯性有助于理解软件构件间的关系（如需求、设计和源代码模块）。同时，有助于理解开发过程中设计决策背后的基本原理[10]。应该尽可能地追溯变更，使文件可以追溯到具体的变更请求。同样，当实施变更请求时，应该可以跟踪文件的变更。与变更请求相关的文件不仅仅是源代码，还应该包括测试用例、文档等受变更影响的所有文件。另一方面，可追溯性能够确切地知道一个特定建立或发布的内容——配置项包含一个特定文件的某个特定版本。良好可追溯性的主要优势是可以更好地进行影响分析，了解变更的结果和提高个人与团队的协调性[9]。

变更请求涵盖：预算变更、需求变更、需求删除、工具更新、硬件配置项和实现变更[7]。敏捷软件开发中，需对变更配置项进行影响分析，考虑需求、用户故事、测试是否需要变更。提出变更申请后，项目软件配置控制委员会（SCCB）进行变更影响分析。影响分析通常应考虑对系统、硬件配置项、相关产品、工作量、进度、质量等带来的影响，同时还应识别并分析可能存在的技术、管理及人力等方面的风险。在某次迭代阶段中，开始设计、编码的需求在该次迭代期间通常不能变更。如经影响分析表明必须马上进行变更，则应终止该次迭代，重新策划并启动新的迭代。本次迭代过程中未对上次迭代工作产品进行变更，则不需走变更流程，直接建立迭代产品。变更流程如图2所示[7]。

图2 软件变更流程图[7]Fig.2 Software change flow chart[7]

2.3 配置状态纪实

配置状态纪实的目的是为了保持经理、用户、开发人员和其他项目利益相关方了解各配置阶段的演变。配置状态纪实与配置识别不同，不是一个预先开展的活动，而是事件触发随时添加的活动。需要根据项目的进展情况，记录配置项的出入库、变更状态。配置状态纪实包含三个基本任务：数据采集、数据记录和报告生成[11]。配置状态纪实通过记录并报告各配置项变更的申请、批准和实施来跟踪变更现状，提供配置项及影响配置项活动的所有信息，包括配置项的变更日志、进度报告和事务日志[12]。

配置状态纪实涉及如下信息的存储和维护：

（1）产品的配置信息（如变更编号、安装信息）；

（2）产品的运行和维护文档信息；

（3）软件配置管理过程信息（如变更请求状态）。

一个好的状态纪实系统应该能够回答如下问题：

1）项目的状态是什么？

2）影响变更请求的事项是什么？

3）实现变更请求的版本？

4）变更请求分配给谁？

5）目前有多少高优先级的变更请求未实施？

6）新版本有什么不同？

2.4 配置审核

配置审核用来验证配置库中的配置项是否符合特定的标准或需求的一种审核手段[7]。配置审核分为功能审核、物理审核、配置管理审核三种类型，最常用的审核类型为功能审核和物理审核。功能审核用于检查软件配置项的正确性和完备性，主要内容为核查软件实现的功能、性能等是否符合用户要求，以及软件的支持文档是否齐套。敏捷软件开发中，功能配置审核可以通过单元测试和验收测试来实现。物理审核则从“准入条件”的角度检查进入配置库的配置项是否已通过了相应的评审或测试及其齐全性，同理，在配置项出库时，同样需检查出库配置项的齐全性与版本的正确性。物理审核是一种对覆盖存储配置项的所有物理载体的检测，当被审核的对象是可安装程序时，还需确认其可以被正确的安装。配置管理审核检查配置管理记录和配置项是否完备、一致和准确。

在敏捷软件开发中，配置项相关记录存在于多重数据库或配置管理系统。在这种情况下，为了确保正确性、一致性、非正式配置项的完整性，配置审核应该涉及这些数据库。配置审核可以看作一个验证活动，实际工作可以被视为质量保证活动，并覆盖于软件开发的其他过程和活动之中。实际工作中，配置审核可以通过验证活动开展。

2.5 配置管理对敏捷活动的支持

与软件配置管理密切相关的敏捷活动有：并行工作、持续集成、规则建立、重构、测试驱动开发等。本节将介绍软件配置管理技术如何支持和加强并行跟踪和持续集成两项敏捷活动[13]。

敏捷团队并行工作在相同系统，需同步更新共享数据和保持数据的双向一致性。并行工作需要解决的问题有“共享数据”、“同步更新”和“双向维护”。

“共享数据”问题很容易解决。创建一个包含所有代码的物理或虚拟工作空间，用于隔离其他人的变更。了解团队其他成员的变更并将变更内容添加到工作空间。

“同步更新”问题只发生在同一时间多人同时修改相同的代码。解决方案也是相当简单的。需要能够检测到配置库中的最新版本，而不是用于变更的历史版本。这时，需要集成并行变更并将合并后的变更结果添加到配置库。

“双向维护”问题是由保护共享数据问题引起的。在多个工作空间中，每一个文件的多个副本很快不再是相同的。当对一个工作空间的文件进行了变更，为保持所有副本相同，需对其他工作空间的所有副本进行相同的变更。这听起来复杂，但其实非常简单。只需要将每次变更后的工作产品放到配置库，其他成员进行变更时从配置库提取，并将变更并行集成。

持续集成意味着团队成员需频繁地整合变更，需尽可能快地响应变更，并能够在真实环境尽早开展变更测试。持续集成要求每一个团队成员整合其他成员的变更，并尽早发现不正确的变更。由于频繁的集成可以尽早发现不正确的变更，降低了整体开销，进而减少了复杂集成问题[14]。

与传统软件开发相比，持续集成导致变更的速度增加，因此保持变更的双向一致变得尤为重要。将变更合并到配置库需要两个步骤。第一步：实施所有变更前，需从配置库中“下载”最新集成结果；第二步：变更完成后，将个人工作空间内容合并后再“上传”到配置库。如图3所示，一个盒子代表配置项的一个新版本，如果配置库没有任何变更，可以安全地将变更后的配置项作为最新版本“上传”到配置库。如果在变更前配置库有新版本的文件，可以简单的更新个人工作空间。如果变更开始后，配置库有新版本的文件有可能引起变更冲突，必须先合并配置库的所有变更，再更新个人工作空间。可以通过各类测试（如单元测试、验收测试等）来检验集成结果的质量。检验正常后，将个人工作空间的最新版本上传配置库。

图3 下载和上传集成图[9]Fig.3 Download and upload integration figure[9]

3 配置管理在Scrum模型中的应用

Scrum模型是最常用的敏捷模型，本节将介绍Scrum模型中的配置管理活动，如图4所示。在进行总体策划前，需已建立功能基线。总体策划时，先标识配置项和基线；制定并评审配置管理计划；根据识别的配置项和基线，在配置库中建立项目目录。每次迭代中，需对迭代工作产品进行管理，集成上一次迭代的工作产品并进行测试。最后一次迭代，评审并测试完整工作产品，将工作产品入库并发布，建立相应基线。在模型的整个生命周期内，为保证工作产品的正确性和完整性，需对产生的工作产品进行配置控制、配置状态纪实、配置审核。

4 结束语

相比传统的软件开发方法，敏捷方法更强调快速灵活响应、积极适应变化，主张客户与开发团队更紧密地协作。基于敏捷的这些特点，在敏捷软件开发中配置管理是非常重要的。在敏捷开发中使用软件配置管理能更好地支持可追溯性和跟踪变更，为需求、缺陷和实现之间的双向可追溯性提供一些额外的作用。本文通过介绍配置管理的定义和活动，引出敏捷软件开发中的配置识别、配置控制、配置状态纪实、配置审核四项典型配置管理活动，可以看到敏捷软件开发中的配置管理活动与传统方法的具体实施有所不同。文中还介绍了Scrum模型中配置管理活动的具体实施方法。

图4 S crum模型中的配置管理活动图Fig.4 Configuration management activity diagram in Scrum model

[1] 任甲林. 木以载道——软件过程改进实践指南[M]. 人民邮电出版社, 2014, 4: 347.

[2] Mary Beth Chrissis, Mike Konrad, Sandy Shrum. CMMI for Development[S], Version1.3. NewYork: Software Engineering Institute, 2011: 137-148.

[3] Angelina Espinoza, Juan Garbajosa. A study to support agile methods more effectively through traceability[J]. Innovations Syst Softw Eng (2011) 7: 53-69.

[4] Fletcher J, Cleland-Huang J (2006) Softgoal traceability patterns. In: Proceedings of the international symposium on software reliability engineering (ISSRE). IEEE Computer Society, Washington, pp 363–374. ISBN:0-7695-2684-5. [5]Leon, A. (2005). Software configuration management handbook. Artech House.

[5] 解晶晶. 基于敏捷开发的软件配置管理[J]. 电子信息对抗技术, 2016, 31(1): 74.

[6] Lara Drvodelic Cvitak, Zeljka Car. Impact of agile developmentation on configuration and change management in telecom domain[J]. PIPRO, 2010.

[7] Mikael Lindvall, Vic Basili, Barry Boehm, et al. Empirical Findings in Agile Methods[J]. Springer Berlin Heidelberg,2002, 2418: 197-207.

[8] Ioannis G.Stamelos,Panagiotis Sfetsos. Agile Software Development Quality Assurance[M]. London: INFORMATION SCIENCE REFERENCE, 2007: 142-145.

[9] Kannan Mohan, Peng Xu, Lan cao. Improving change management in software development:Integrating traceability and software configuration management[J]. Decision Support Systems, 2008: 922-936.

[10] Andreas Beergstrom. Software Configuration Management in Scrum Projects[D]. Department of Computer Science Lund Institute of Technology Sweden, 2007: 9-10.

[11] Juha Koskela. Software configuration management in agile methods[P]. VTT Electronics, 2003: 14.

[12] B Loppin,P Couble. Software Configuration Management in Agile Development[J]. Clinical Oral Implants Research,2010, 21(1): 55-64.

[13] Abu Wahid Md,Masud Parvez. A Managed Approach to Interact between Agile Scrum and Software Configuration Management System[J]. Advances in Information Technology and Management(AITM), 2012: 111-114.