软件项目配置管理工具的使用体会 高效的工作必定是有序的管理和投入的工作结合产生的。

软件项目配置管理，不仅对团队开发而已具有必不可少的重要性，能够帮助团队成员搭建统一的开发环境、对软件代码进行版本控制、管理项目文档以及为团队成员提供正式、有规则的交流平台，对于个人开发依然具有极大的帮助，比如它的版本控制功能和文档的管理功能。因此，在软件项目开发中，必须使用配置管理软件协助开发过程，而选择何种管理软件和使用的方法同样也是很重要的事。

到目前为止，我使用或是了解了共三款项目配置管理软件（组件），分别是Maven，GitHub和SVN。接下来，

一、首先分别大致介绍三款软件的特点和优劣；

二、然后在限定范围内，对这三款软件进行比较；

三、最后陈述我的个人看法和体会。

一、关于三款软件的简单介绍

Maven：

Maven是基于项目对象模型(POM)，可以通过一小段描述信息来管理项目的构建，报告和文档的软件项目管理工具。

Maven 除了以程序构建能力为特色之外，还提供高级项目管理工具。由于 Maven 的缺省构建规则有较高的可重用性，所以常常用两三行 Maven 构建脚本就可以构建简单的项目。由于 Maven 的面向项目的方法，许多 Apache Jakarta 项目发文时使用 Maven，而且公司项目采用 Maven 的比例在持续增长。

Maven最大的特点是只需要简单的构建工程即可使用，能够有效地帮助开发人员了解、获取与、统一工程开发所需的开发包。尤其是在协作开发的环境下，Maven有效地解决了各个开发成员间可能存在的开发包版本不一致问题，避免了后期因此产生的版本冲突。 通过上面的描述也能发现，Maven虽然易于使用，但主要用于项目初期时对项目创建的统一管理，这也是Maven的局限性。对于大型项目而言，使用了Maven之后，还必须使用其它针对项目创建之后过程的项目配置管理软件，这样才能有效地进行项目配置管理。

GitHub：

GitHub作为一个分布式的版本控制系统，并不存在主库这样的概念，每一份复制出的库都可以独立使用，任何两个库之间的不一致之处都可以进行合并。

GitHub可以托管各种git库，并提供一个web界面，但与其它像 SourceForge或Google Code这样的服务不同，GitHub的独特卖点在于从另外一个项目进行分支的简易性。为一个项目贡献代码非常简单：首先点击项目站点的“fork”的按钮，然后将代码检出并将修改加入到刚才分出的代码库中，最后通过内建的“pull request”机制向项目负责人申请代码合并。

已经有人将GitHub称为代码玩家的MySpace。

在GitHub进行分支就像在Myspace（或Facebook?）进行交友一样，在社会关系图的节点中不断的连线。

GitHub项目本身自然而然的也在GitHub上进行托管，只不过在一个私有的、公共视图不可见的库中。开源项目可以免费托管，但私有库则并不如此。Chris Wanstrath，GitHub的开发者之一，肯定了通过付费的私有库来在财务上支持免费库的托管这一计划。

也就是说，GitHub最大的特点是支持分布式的项目管理，项目开发团队可以在Git上创建一个项目总库，再由开发成员在各自的开发设备上维护相应的分支（甚至也能维护总库的克隆版本），当需要提交代码时，GitHub将自动比对总库和分支，检测冲突性的提交，标注更新的部分，最终完成总项目的更新。此外，GitHub还是开发成员相互讨论的平台。

GitHub提供了专门的讨论空间，开发人员可以就某一主题进行讨论，讨论的内容相当于作为记录被保存下来，能够被日后再次查看，这也能帮助某分支以外的人员了解该分支情况，进而减少不必要的交流，有效地提高了团队的整体效率。

从使用的阶段而言，GitHub和Maven是互补的，可以先利用Maven创建总工程，然后将工程通过GitHub进行管理，分派到各个项目成员中。这样做，不仅保证了所有项目成员开发库的一致性，还对项目正式分工之后的过程保持管理，促进成员沟通、保留讨论记录。如果中途出现开发库的重大更改，可以重复创建过程，也就是说，这种情况下Maven和GitHub可以迭代使用，以保证对项目开发进行有效管理。

SVN：

上述的Maven和GitHub在使用阶段方面已经涵盖了软件项目开发的全过程，所以如果从如何有效利用项目配置管理软件来完成一个项目的角度来说，似乎也不必再了解其它软件了。但是，选择需要的软件时，除了从适合的使用阶段考虑，项目的规模、项目的类型、项目的特殊要求等方面进行充分考虑。

SVN和GitHub的共同之处是，二者都是开放源代码的版本控制软件，同时也都采用了分支管理系统，然而与GitHub的分布式特征相反，SVN是集中式管理。

集中式代码管理的核心是服务器，所有开发者在开始新一天的工作之前必须从服务器获取代码，然后开发，最后解决冲突，提交。所有的版本信息都放在服务器上。如果脱离了服务器，开发者基本上可以说是无法工作的。

然而，相对于分布式管理而言，集中式管理最突出的优点就是便于管理和安全性。 SVN站在更高层次上对安全产品，从系统和控制的角度进行了"有机"和"无隙"的整合。 SVN是一个安全虚拟网络系统，它将系统整体的信息安全功能均衡合理地分布在不同的子系统中，使各子系统的功能得到最大限度的发挥，子系统之间互相补充，系统整体性能大于各子系统功能之和，用均衡互补的原则解决了"木桶原理"的问题。

SVN能在跨接Internet,Intranet,Extranet间的网络所有端点实现全面的安全，而且还能提供基于企业策略的信息管理机制以充分有效地利用有限的带宽。SVN可以满足各种企业VPN的要求，通过为公司内部网络、远程和移动用户、分支机构和合作伙伴提供基于Internet的安全连接。所以，我们可以将SVN看成是VPN、防火墙、基于企业策略的信息管理软件集成在一起的Internet安全的综合解决方案。在这样一个网络系统中，所有互联网服务器端和客户端都是安全的，并有一个信息管理机制以不断地通过这个外部网络环境动态地分析及

满足客户的特定带宽需求。

要体现SVN的优缺点，这里还需要提到的是CVS。

CVS（Concurrent Versions System）版本控制系统是一种GNU软件包，主要用于在多人开发环境下的源码的维护。Concurrent有并发的、协作的、一致的等含义。实际上CVS可以维护任意文档的开发和使用，例如共享文件的编辑修改，而不仅仅局限于程序设计。CVS维护的文件类型可以是文本类型也可以是二进制类型。CVS用Copy-Modify-Merge（拷贝、修改、合并）变化表支持对文件的同时访问和修改。它明确地将源文件的存储和用户的工作空间独立开来，并使其并行操作。CVS基于客户端/服务器的行为使其可容纳多个用户。这一特性使得CVS成为位于不同地点的人同时处理数据文件（特别是程序的源代码）时的首选。

再回到SVN，所有的文档都显示SVN可以取代CVS，同时SVN的问题和缺点都被隐藏了。不然而，并不是说SVN是CVS的替代品，尽管很多缺陷都被修改了。更有甚者，它甚至让人重回CVS。CVS和SVN的比较类似于比较C++和Java。很明显CVS和SVN都远比SourceSafe强大的多，如同C++和Java比Basic强大的多。CVS代表了几乎代码控制系统的所有功能项，尽管有时他的实现并不很方便。SVN修正并添加了一些CVS并不拥有功能。例如，创建标志和分支dubious，你在编辑文件时其他人不会有任何通知。SVN并不是CVS的替代品，只是个不同的系统，类似于CVS。它有些特有的功能，足以作为采用它的理由。这些功能使他更适合于开发环境，例如对PowerBuilder。下面你可以找到两者的相对优势、劣势。

1 存储类型格式

CVS是个基于RCS文件的版本控制系统。每个CVS文件都不过是普通的文件，加上一些额外信息。这些文件会简单的重复本地文件的树结构。因此，不必担心有什么数据损失，如果必要的话可以手工修改RCS文件。

SVN是基于关系数据库的(BerkleyDB)或一系列二进制文件的(FS_FS)。一方面这解决了许多问题 (例如，并行读写共享文件)以及添加了许多新功能(例如运行时的事务特性。)。然而另一方面，数据存储由此变得不透明。

2 速度

CVS比较慢。

整体而言,由于架构实现的不同, SVN的确比CVS快很多。在网络上它只传输很少的信息并支持更多的离线模式的功能。但这也是有代价的。速度的代价就是巨大的存储（完全备份所有的工作文件）。

3 标志&分支

SVN把采用标志和分支而抛弃了其他三件东西，实际上这意味着他们把这个概念替换为在档案库内部复制文件或目录以便保存日志。这样一来，无论标志创建还是分支创建都只是仓库内部的文件复制了。对分支而言：分支不过是在仓库内部的一个单独的目录而已了，不像早期还有些什么交错。对标志而言：已经不能对代码加标志了。在某种程度上说，SVN全文件编号补足了这个缺陷，SVN里整个仓库都有版本号，但不是针对单个文件。

4 元数据

CVS只允许存储文件。

SVN允许一个文件有任意多的可命名属性，功能十分完全。

5 文件类型

CVS最初是为文本文件存储而设计的。因此其他文件类型（二进制，统一码）文件的支持几乎没有，如需要的话则要有其他信息，并且客户端服务器端都要调整。

SVN会关心所有的文件类型，不需要你来手工操作。

6回滚

CVS允许任意的回滚，在任意一个已递交的版本上，尽管这要花些时间（所有的文件都要分别处理）。

SVN不允许递交后回滚。建议把版本库里好的状态版本加到末尾，覆盖掉损坏的版本。而损坏的版本无论如何也是会存在数据库里的。（SVN的滚回操作实际上是merge操作）

7事务

CVS中的“零或一”事务原则根本没有实现。如果检入几个文件的话（加到服务器上），很有可能部分文件完成了，而另几个没有。作为一个潜规则，手工纠正这些并且对余下的文件 (而不是所有文件)一一重复检入。这样这些文件将在两阶段中被检入。SVN的确支持“零或一”事务原则，这是SVN的一大优势。

二、在限定范围内比较三款软件

以上即是对这三款管理软件的简单介绍，在实际选择过程中，可能会考虑到使用软件的成本、软件的复杂程度、软件适用的编程语言或是软件的安全性等等众多方面，但暂时不关心其它方面，仅从项目规模大小、项目开发阶段和项目管理严格程度三个方面比较三款软件。

在项目规模方面，由于Maven主要是用于项目创建初期准备一致的开发库，所以无论软件规模大小，都可以先使用Maven创建项目。SVN采用集中式管理，工作时总是需要核心服务器支持所有开发人员，服务器的运行负荷十分巨大，一旦服务器发生问题，所有人的工作都会受到影响。而由于GitHub采用分布式管理，用于管理项目的服务器运行负荷相对而言减轻许多，而即便某一部分发生问题，也能从其他服务器上通过预先设置的文档属性获得停止工作服务器上的文档，不会对项目开发过程造成分布式管理中那样巨大的影响。但正如通常所了解到的那样，分布式管理虽然更加稳定，但在管理难度上也大大增加，所以，对于小型软件开发项目，SVN更加合适；而对于大中型软件开发项目，GitHub将成为更加有利的选择。

在项目开发阶段方面，像前面所提到的那样，Maven主要针对项目开发所需要的开发库进行管理，因此更适合用于项目的创建阶段。而GitHub和SVN则适合用于项目创建之后的阶段。

在项目管理严格程度方面，鉴于Maven和其它两款软件适用于不同的阶段，也不用再将Maven纳入考虑范围之内。这里的严格程度被解释为项目文件安全程度的严格，集中式管理的最大优势是完全控制着项目的变更和访问，而分布式管理能够控制项目的变更，但在控制访问的能力方面来说，是很难和前者相提并论的。

三、个人看法和使用体会

现今的项目配置管理软件众多，可从开源和付费的区别开始划分，付费的软件会根据客户需求及时更新，软件的质量也常常优于开源软件。然而，开源软件的优势正是在于免费使用和允许广大开源工作者共同劳动，因此具有更强的可塑性和发展潜力。

我所接触到的开源类型软件即是以上提到的GitHub和SVN，就体验而言，GitHub是更加适合我使用的，因为目前我所需要的功能和性能要求都能被二者很好的满足，但GitHub还提供了诸如讨论、对更新内容的特别备注等附加功能，因此带给我更好的使用体验。

但也正如这篇文章描述的那样，在实际工作中，一款项目配置管理软件的选择存在许多需要认真度量的方面，只有先认识到项目开发各方面存在的需求和开发全过程中可能出现的问题，才有选择何种软件的依据。因此，使用项目配置管理软件时，重要之处不仅在于如何合理使用软件满足项目开发的需求，还在于借助软件研究项目开发过程，以期积累尽可能多的好的经验，让每一次项目开发都留下有价值的遗产，能够被用到更多、更复杂的项目开发中去，这正是当管理软件和项目开发相结合时，重大的隐藏价值所在！

 

第二篇：软件配置管理实施体会

软件配置管理实施体会

陈越，fashi@etang.com

随着软件产业的崛起，软件工程技术正吸引着越来越多关注的目光。作为软件工程的一个重要的领域，软件配置管理（Software Configuration Management）也日益受到人们的重视。在这里，笔者并不打算对软件配置管理的细节进行讨论，几乎任何一本关于软件工程的教材中都有专门的章节对此进行介绍，而是想从一个实践者的角度来阐述关于软件配置管理的一些想法。

一． 软件配置管理的目的

对于任何一个软件组织（企业）来说，开发出满足用户需求的、高质量的软件产品是其追求的目标。而要实现这一目标的关键是建立起一个稳定、可控、可重用的软件流程（Software Process）。因为某一软件产品的成败可能维系于关键技术的突破和创新；但对于软件组织而言，要想永葆竞争优势并不断取得成功，那就必须不断地改进它的软件流程。要进行软件流程改进（Software Process Improvement）就需要有明确的、量化的对现状的分析和对未来的预期，这些数据来源于对软件过程的度量，而进行度量的前提和基础就是软件配置管理。

与一般制造业相类似，软件流程就像是一条流水线，在它的各个环节上都会有“零部件”产生，它们就是我们所熟悉的程序、相关文档以及数据。这些正是软件配置管理的对象——（软件）配置项。它们不仅是大量人力物力投入的结晶，更是开发经验的积累，是软件组织最宝贵的财富。软件配置管理贯穿于软件开发活动的始终，覆盖了开发活动的各个环节，它的重要作用之一就是要全面的管理保存各个配置项，监控各配置项的状态，并向项目经理及相关的人员报告，从而实现对软件过程的控制。

那么我们对这些配置项进行管理只是为了保存这些信息吗？众所周知，人员的高流动性和知识和技术的快速更新是软件业的重要特点。应对这样的特点我们只有努力地把开发人员个人的成功经验转化为团队的以及整个组织的经验。在这样的一个转化过程中，软件配置管理也起着极其重要的作用。因为对于一个大型的软件企业来说，它的配置库有如一个巨大的图书馆，随着产品版本的不断演进，越来越多的配置项会充斥其间，以至于没有任何一个人能了解其中的全部内容。当我们需要在开发组织内部迅速的共享以往的成果时，配置管理就能发挥作用了。它就像常见的图书编目法那样，帮助图书管理员（配置管理员）迅速的找出所需的资料（配置项），而不必彻底了解其中的确切内容。这样工作效率大为提高，很多常见的容易引起混乱的问题都能尽量得以避免。

所以，我们在从事软件配置管理工作时应以整个软件流程的改进为目标，为软件项目管理和软件工程的其它领域打好基础，以便于稳步推进整个软件组织的能力成熟度。

二． 工具的选择

古语有云：“工欲善其事，必先利其器。”软件配置管理是一项十分繁琐的工作，同时又和整个软件的开发活动紧密地联系在一起，所以在实际工作中更需要有得力的工具辅助。目前常用的配置管理工具主要有MS SourceSafe、Rational ClearCase等，这些工具各有所长，因而只有根据项目

的预算和开发组织的些实际情况出发来选择，正所谓“好用就好”。在这里，笔者提出一些个人的看法供大家参考。

首先，配置管理工具应该提供完善的版本管理的功能。在该工具的所管理的配置库中，所有的配置项都应清晰、完整的得到保存，相应的操作纪录完备，使得开发组织中的任何人员都能迅速的了解任一配置项的演进过程，并快捷的找到所需的资源。

其次，配置管理工具应具备一定的工作空间的管理功能。正如前文指出的那样，一个软件企业往往有多个项目同时进行着开发，为了最大程度的利用组织的经验、共享成果，我们有必要在一个共同的配置库里提供多视角的观察手段，在逻辑上按照不同的角色分工来组织信息的选取规则和显示方式，从而能根据需要，在开发人员间灵活的进行分工合作。

由于我们把配置管理工作立足于软件过程的改进，那么我们所选用的工具最好能具有一定的过程控制的能力，能利用它按照企业本身的开发流程来灵活的建立相应的电子流，并在此过程中记录用于过程度量的相关数据，整合软件过程管理的各个环节，以便于客观的发现问题，高效的解决问题。

另外，我们选取得工具一定要操作简便，不能给开发人员增加过多的负担，因为过多的形式化的约束往往带来人们的反感，使得大家不约而同的选择规避的措施，其结果只能是事倍功半，甚至和我们的目标南辕北辙。

三． 实现的策略

笔者所在的软件组织从事的通信软件的研发，我们把配置管理作为推进软件过程改进的一个很重要的工作领域。我们明确定义了配置管理相关的角色、工作职责和工作流程，通过一段时间的努力，已经取得了明显的效果。 1． 配置库的设置

决定配置库的结构是配置管理活动的重要基础。一般常用的是两种组织形式：按配置项类型分类建库和按任务建库。

按配置项的类型分类建库的方式经常为一些咨询服务公司所推荐，它适用于通用的应用软件开发组织。这样的组织一般产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向和各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。 而按任务建立相应的配置库则适用于专业软件的研发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格的分类存储，人为增加目录的复杂性。因此，笔者认为特别是对于研发性的软件组织来说，还是采用这种设置策略比较灵活。

2． 分支的划分

在实际的开发活动中系统中，为了让每个开发人员和各个开发团队能更好的分工合作，同时又互不干扰，我们基本上为每个配置项从建立开始就划分成3个不同的分支，让它们分别对应3类工作空间。

l 私有分支

私有分支对应的是开发人员的私有开发空间。开发人员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的元素。

l 集成分支

集成分支对应的是开发团队的公共空间。凡是要为同组人员共享的配置项都从该分支获得。即各开发人员必须将私有工作空间中的开发成果归并（Merge）到该分支后才能进入下一个开发活动。所有涉及多人协调的开发工作（如集成测试等）都必须工作在这一空间中。该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限。该分支的管理工作由系统集成员及相关指定人员负责。

l 公共（主干）分支

公共分支对应的是整个软件开发组织的公共空间。各个开发小组在现阶段的任务完成后，将可以发布的版本归并到该分支上，将来需要查阅相关资料时，以该分支上的版本为准。该分支对组织内的全体软件人员开放只读权限。该分支的管理工作由系统集成员负责。

上面定义的3类工作空间（分支）由配置管理员统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。 3． 变更控制

对于大型的软件开发项目，无控制的变更将迅速导致混乱，变更控制就是通过结合人的规程和自动化工具，以提供一个变化控制的的机制。本文所涉及的变更控制的对象主要指配置库中的各基线配置项。变更管理的一般流程是：

A) 由开发人员或系统集成员提出变更需求；

B) 由SCCB（软件变更控制委员会）审核并决定是否批准；

C) 配置管理员根据SCCB的决定临时开放相应的权限，并备案；

D) 系统集成员执行相应的变更。

在这里，将要涉及的变更控制分为两类：一类是基线的变更控制，另一类是软件版本的变更控制。 l 基线的变更控制

基线的变更是指在一个软件版本的开发周期内对基线配置项的变更，主要包括基线的应用和更新等活动。

基线变更所涉及的操作主要包括基线标签的定义和标签的使用。基线标签属于严格受控的配置项，它的命名必须严格按照相关的命名规范来进行。基线在建立时，按照角色职责的分工，须经SCCB同意并以正式的将该基线的标识和作用范围通知系统集成员，由后者负责执行；基线一旦

划定，由该基线控制的各配置项的历史版本均处于锁定或严格受控状态，任何对基线位置的变更请求都必须按变更控制流程，提交SCCB批准，然后由系统集成员执行。

l 软件版本的变更

软件版本的命名规范应事先制定，并按照开发计划予以发布使用。在软件版本的演进过程中既需要从以前的版本中继承，又需要相对的独立性。所以在对于一个子版本（例如某特定用户的定制版本）就需要对一系列配置项从统一的开发起始基线所确定的版本上建立新的分支，然后在此分支上开发新的版本。因此在这样的变更控制流程中，受控的对象还应包括特定的分支类型，以及工作视图的选取规则，同时配置管理员将在这一过程中担负更多的操作职责。

上述几点是笔者在从事软件配置管理过程中的一些心得体会，在此抛砖引玉，供大家参考。 本文来自《PMT评论》总第23期