小公司如何实施配置管理

小公司如何实施配置管理（一）

背景：对于配置管理来说，配置库是保存公司资产的仓库，属于逻辑概念，而实现上，可以根据实际情况以及以往的习惯，选择适当的工具来辅助配置管理工作的实施。常见的用于支持配置管理的工具有CVS、Subversion、VSS、starTeam、CC等等。基于费用以及维护工作量的考虑，优先考虑CVS和Subversion。

区别：cvs 和svn有着较大的差别，

1）cvs在server上保存的是workspace的实际拷贝（意思是你能够在服务器上找到一个目录和本地工作空间的内容一 模一样的），而svn在server上保存的是转换过的数据（与本地工作空间的内容完全不一样），

2）cvs的把版本信息和修改内容是通过与文件相关联的附属文件进行记录的，而svn是通过全库快照进行保存的，

3）基于2的原因，cvs中，各个文件都有自己的版本，而svn中同一时间所有文件的版本都是一致的（单库），

4）也基于2的原因，cvs只能对文件进行版本控制，文件夹不在控制范围之内，而svn则能控制文件和文件夹，并且有历史版本信息。

5） cvs上tags和branch的实现是通过在文件的附属文件中添加标记来标识某一个版本的内容范围，而svn则是通过copy的方式实现。

　　选择：对于实施配置管理来说，cvs比较接近CMMI中版本和基线跟踪的概念，但是基于cvs的第三方支持工具相对较少（也许未发现）和以往的开发习惯，还是决定使用svn来实现配置库。

　　概念：对配置管理来说，需要有几个逻辑库的概念，1）开发库，用来保存开发过程中的不稳定源码；2）文档库，用于保存开发过程中不稳定的文档；3）产品库，用来保存阶段性发布的产物（源码和文档）。

　　策略：我们会将这些不同的库集成在一个或多个实体库之中。对与svn来说，同一个库内的任意文件的修改都会导致整个库的版本号递增，因此需要通过多库来隔离变化。

　　分析：1） 不同的项目需要在配置库中实现统一管理，2）各个项目的文件夹具有相应的访问控制权限，3）可以通过http进行远程访问，4）ssl安全访问（可选）， 结合上述需求以及潜在需求分析，确定配置库需实现如下功能：1）文档库、开发库、产品库的版本不相互影响，2）默认权限：项目leader具有的权限（开发库：rw，文档库：rw，产品库:r），开发人员具有的权限（开发库：rw，文档库：r，产品库：none），技术总监具有的权限（开发库：rw，文档库：rw，产品库：rw），配置管理员具有的权限（管理权限），3）能够实现基线的概念和实现基线跟踪。4）需要添加一个构建库的概念，用于给STE提供稳定的测试版本。

　　实现：在一个svnserver中使用多库共存，分别为，开发库（dev），文档库（doc），产品库（pd），构建库（db），然后将多库的顶层目录映射为apache的一个虚拟目录，通过apache的svn module进行访问权限控制（rw权限），通过LDAP进行webdav的访问控制（access权限）。

　　总体过程：1） 项目启动：项目经理（PM）填写项目初始化申请书，提交配置管理员（CMO），2）CMO根据项目名称、优先级、配置库类型、访问列表及权限要求，对配置进行初始化，填写回执返还PM，3）PM与开发团队验证访问权限，然后开始文档开发和源码开发工作，4）文档和源码经过严格评审后，建立各自相应的基线， 5）该阶段的所有配置项都经过最后的基线化后，建立产品基线。6）发布版本。

　　变更过程：对于小型公司来说，对所有库都进行严格的读写控制会带来较大的工作量，因此，对应的做法是只对文档库和产品库做变更控制，不为开发库做变更控制。

　　文档基线化过程：文档开发人员完成文档开发后，由PM组织评审会议，确定无问题后，将文档上传文档库，为1.0版本；出现变更并确定要变更后，文档开发人员修订文档，再次进行评审，通过后形成1.1版本。后续的环节进行变更迭代。到阶段性产品基线建立的时候，作为产品基线的一个元素纳入产品基线。

　　源码基线化过程：源码开发人员完成模块或子系统开发后，通过运行自动构建（跑单元测试和集成测试）得出单元测试通过率和集成测试通过率，PM将这些信息提交测试经理（TM），TM到构建库（ftp或share folder）获取开发版本，组织预测试（Quick Test：运行基本功能测试套件），判断交付版本是否具有足够质量支撑后续工作，若有，进入该版本的系统测试，否则，退出打回版本。通过测试退出标准后，freeze该项目的源码。

　　产品基线化过程：当阶段性文档和项目源码都基线化后，PM提交产品基线化申请书，其中包括产品基线的名称以及该产品基线具有的所有元素的基线名称列表，CMO收到足够信息后，在产品库建立完成的产品基线。

　　产品发布过程：PM提交产品发布申请书（产品基线的名称，产品基线中需交付的元素名称列表），CMO获取足够信息后，对待发布元素进行打包，在发布申请书上填写处理结果，待PM确认后，完成产品内部交付过程。

　　自动构建过程：通过引入自动构建工具，监控开发库的所有变化，每当开发库有修改，都会触发自动构建，完成后以邮件形式在将修改的文件列表和修改者的信息发给PM和QA和TM，进行三方源码监控，保证源码的有效性和正确性。

以上是个人的一些关于如何实施配置管理过程，以及配置管理与关联过程的交互方面的积累，一人计短，难免会有bug的出现，欢迎大家共同讨论。

小公司如何实施配置管理（二）

在上一篇《小公司如何实施配置管理（一）》中，我们主要阐述了小公司如何实施配置管理的设计方案，包括配置管理的一些基本概念、配置管理工具的对比、配置管理的需求、以及部分配置管理的子过程设计，本篇的主要目标是结合《小公司如何实施配置管理（一）》中的设计方案，初步给出实施方案。

结构：配置库分为开发库、文档库、产品库、构建库，这四个库分别是独立的单库，版本不相互影响。上述四个库的第一层目录均为项目全称的缩写字母（lowcase）。例如，项目一在开发库下的相对路径为：/dev/pro1，在pro1下为该项目的具体源码结构树；项目一在文档库下的相对路径为： /doc/pro1，在pro1下为该项目的文档树结构（包括且不限于项目立项、项目结项、项目计划、项目监控、风险管理、配置管理...），相应的文档放入到相应的文件夹中；项目一在构建库下的相对路径为:/db/pro1，在pro1下为该项目不同时期的构建版本（格式：项目缩写_阶段_主版本.次版本.修订版本-YYYYMMDD.后缀名）；项目一在产品库下的相对路径为：/pd/pro1，在pro1下为该项目不同时期的基线发布，如1.0基线包括的所有发布内容（交付文档和源码）统一保存在/pd/pro1/1.0/路径中。

实现：采用ubuntu ＋ apache ＋ subversion + openldap， apache实现http或https方式通过webdav协议浏览svn目录结构，openldap实现web的安全访问验证。

总体步骤：1.安装Ubuntu基系统，2.更新基系统所有组件，3.安装apache2、subversion、libapache2-svn、 slapd、ldap-utils，4.建立ldap目录结构（group & user），5.创建配置库结构，6.整合apache2和subversion（权限和虚拟目录），7.整合apache2和ldap（web访问验证），8.域名绑定。详细的配置过程将会在后续的文章中进行阐述。

注意：由于subversion对URL是有规则截取的，规则：只使用域名或IP地址后的内容作为配置库的寻址路径，因此，只能使用域名直接映射IP地址的方式，而不能使用域名映射为IP/context的方式。

到此我们已经把基于配置库的配置管理框架搭建起来，但是工具只是用来辅助管理的，重要的还是过程，在配置管理中，变更管理、配置审计、状态统计等等支撑过程，还没有完全的确定下来，没关系，事情是不能一蹴而就的，在后续的篇章中，我们会逐个阐述，分析和交流这些过程实施的重点和难点。

以上是个人的一些关于如何实施配置管理过程，以及配置管理与关联过程的交互方面的积累，一人计短，难免会有bug的出现，欢迎大家共同讨论。