软件配置管理最佳实践.docVIP

软件配置管理最佳实践 PMTeam杂志 Li Ben 编现在大家都已经认识到了有效的软件配置管理工作对于提高团队开发效率、保障软件产品质量的重要意义，很多朋友也开始了在配置管理实施方面的一些研究，市场上我们也可以看到一些软件配置管理工具厂商针对具体配置管理工具提供的实施服务；但是，实施软件配置管理到底应该做哪些东西？团队的配置管理现状怎么评估？在哪些方面还可以进行改进？我们相信，这些问题可能正困扰着大多数研发主管和项目经理。 国外软件产业界在软件配置管理这个专题上已经进行了多年的理论和实践上的研究。在多年经验积累的基础上，产业界总结出来一系列“最佳实践”（Best Practices），我们可以使用这些“最佳实践”来作为评估一个组织软件配置管理能力的标尺，也可以作为我们实施软件配置管理的指南。这些“最佳实践”包括： 1、 标识需要进行存储的工件（Artifact）并保障安全存储； 2、 控制并且审计（Audit）对于工件的修改； 3、 设立并管理基线（Baseline）； 4、 记录并跟踪变更请求； 5、 维护稳定、一致的工作空间； 6、 支持对于工件和控件的并发修改； 7、 尽早集成、持续集成； 8、 保证软件构建的重现能力； 9、 以控件（Component）为单位实施版本控制； 10、 使用“活动”（Activity）来组织和整合版本集。 下文将介绍前5条最佳实践。 1、标识需要进行存储的工件（Artifact）并保障安全存储在软件开发过程中，我们会得到各种各样的产出，比如各种文档、模型、源代码以及测试脚本等，我们把这些大家劳动的成果统称为工件（Artifact）。对于一个软件开发组织来说，这些工件就构成了组织的核心资产。对于如现金、有价证券之类的资产，我们都会准备一个保险箱，好好地保存；对于软件资产，我们也需要相似的措施。所以，软件配置管理工作的第一步就是建立一个安全、可靠的存储库（Repository），用于保存组织的核心软件资产。 这个库对于开发团队来说，就像是财务室里的保险箱。因此，容错能力和高可靠性是这个库最重要的属性。除此之外，随着组织的增长，置于库中的数据会越来越多，为保证运行效率，库的可扩展性也是非常重要的一个属性。 对于存储库来说，良好规划的备份和灾难恢复过程是必不可少的。令人惊讶的是，很多软件组织在这方面都没有给予必要的重视，因而也给组织的发展留下了严重的隐患，一旦灾难发生，后果不堪设想。 在建立好存储库以后，需要做的工作就是确定将哪些工件置于库中。根据实际需要，组织可能会决定只将正式文档、模型文件、源代码、发布版本等文件放入库中，而对于临时文档、编译时产生的中间文件等，则不将它们放入库中。我们把放入库中的文件称之为配置项（Configuration Item）。 2、控制并且审计（Audit）对于工件的修改在标识相关的工件并将它们置于存储库中以后，我们需要建立对于这些工件的修改控制机制以及审计机制。 库里的工件不是谁想修改就可以修改的。控制机制必须保证只有拿到授权的人员才能对相关工件进行修改，而审计机制则保证修改的动作被完整地记录，也就是说，谁修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及修改了哪些地方（Who、When、Why、What）。 审计机制通常通过“检出/检入”（Check out/Check in）模式得到实现。在这种模式下，工件一旦入库，读写权限就变成只读（read only），如果要对该工件进行修改，则需要通过“检出”这个步骤；在修改结束以后，如果希望将修改的成果入库，则需要通过“检入”这个步骤。在经过一次“检出/检入”步骤以后，会形成该工件新的版本，因此也有人把上边的过程称之为“版本控制”（Version Control）。在版本控制过程中，如果利用一些配置管理工具（或者版本控制工具）的支持，则可以自动地记录审计工作所需的四个“W”（Who、When、Why、What）。 3、设立并管理基线通过审计机制我们可以保存一个工件完整的变更历史；但是一个项目通常是由成百上千个工件构成的，每个工件在变更过程中都会形成一系列的版本，如何确认系统在某个时刻分别由哪些工件的哪些版本构成？这就需要引入一个概念：配置（Configuration）。对于软件系统来说，在开发过程中某个时刻存储库中所有工件的一个“快照”（snapshot），就形成一个“配置”。对于一些重要时刻的系统配置，我们可以使用基线（Baseline）来进行标志。 IEEE对于基线的定义是：已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制过程进行改变 简单地说，基线就是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于这个标准