还剩18页未读,继续阅读
本资源只提供10页预览,全部文档请下载后查看!喜欢就下载吧,查找使用更方便
文本内容:
工程型软件项目的配置管理实例前言 软件配置管理作为贯穿软件__过程始终的一项工作,其重要性不言而喻51cmm上已有众多关于配置管理介绍、配置管理计划、配置管理工作开展心得一类的文章,这些文章从概念和实施上介绍了配置管理工作的内容,但美中不足的是仍嫌抽象,那些想要依葫芦画瓢的兄弟姐妹们在试图将这些理论应用到自己项目的配置管理中的时候,会发现仍然是无从下手(我也曾是这些感觉无从下手的人中的一个)因此,本文拟从另外一个角度,以本人最近实际操作的一个项目的配置管理工作谈起,从配置管理工具的选择、配置管理流程制定、配置管理库结构的确定,以及作为配置管理工作的推动者如何推动这项工作等方面仔细描述一下本人的做法,希望这几篇文章能给那些水深火热中的兄弟姐妹们一点帮助 这里有两点需要特别说明
1、本文描述的内容是以一个项目的配置管理为主线,对组织级的配置管理和配置管理策略没有进行详细讨论;
2、本文用来做示例的项目是一个“工程型”的项目,所谓的“工程型”是和“产品型”对应的,这样的项目需要公司的__人员和现场的__人员进行协作__,一般而言,在公司的__人员完成大部分的功能,现场的__人员根据用户需求,对软件进行修改(这部分的工作量一般会较大,在一个16人年的项目中,这部分的工作可能会占到三分之一以上的工作量) 配置管理工作概述 配置管理工作的工作范围,在51cmm的很多文章中都有描述,具体可以参考河清专栏的《基于CMM和CMMI的配置管理》和陈越的《软件配置管理实施体会》在这里不作详细的描述 本文涉及的项目背景 本文用来示例的项目是某省__的一个项目,该项目的工作量大约是16人年,项目周期约为1年大部分(90%以上)的__工作在前8个月内完成,后期的工作主要由维护人员进行系统维护和调整在8个月的__时间中,前5个月由__人员在公司进行__,根据用户的需求完成设计,确定系统架构并实现整个框架,部分明确的功能以及公用模块也在这段时间内完成;后3个月的时间部分__人员在现场,部分__人员在公司共同完成后期的__工作 整个项目采用的__语言是C++、J__a、ASP,涉及的平台包括Solaris和Windows,采用的__工具包括VisualStudio和Solaris上的CC此外,整个项目还使用了一些第三方的平台,如IBM的MQ等 除用户需求之外,公司还对项目组提出了代码复用方面的要求,__人员在__过程中必须注意代码的可重用性 配置管理前期准备工作 在项目正式启动之后,配置管理工作就可以开始了配置管理工作开始的第一步就是一份配置管理计划51cmm上已有不少配置管理计划的模板,大家可以参考 一般而言,需要在配置管理计划中明确的内容包括
1、配置管理软硬件资源;
2、配置库结构;
3、人员、角色以及配置管理规范;
4、基线计划;
5、配置库备份计划; 在下文中,我们将围绕这些内容进行详细描述 配置管理环境 配置管理环境包括软硬件环境具体的资源需求应该根据项目实际情况来确定,一般需要考虑的包括网络环境、配置管理服务器的处理能力、空间需求,配置管理软件的选择等配置管理环境的确定需要综合考虑各个方面的因素,包括我们采用的__工具,__方式,__人员对配置管理工具的熟悉程度等,其中,__人员对配置管理工具的认可和熟悉程度常常直接决定配置管理能否正常进行,如果选择了需要__人员花费比较大的精力去熟悉的配置管理软件,我们就必须花费大量时间来进行培训;同时,配置管理软件和__工具的集成程度也是一个必须考虑的因素,根据我们的经验,选择一个和__环境集成紧密的配置管理工具至少可以减少20%花费在CheckIn/CheckOut和配置管理人员保持配置库完整上的工作量 根据我们项目的实际情况,我们有如下一些考虑 根据历史经验,一个类似项目的配置库大小约为3G,考虑到备份等操作对空间的需求,至少应该为配置管理库保留10G以上的空间为了保证配置管理库的安全,除了相应的备份计划之外,还可以采用了RAID0+1的方式为配置数据库提供更好的可用性保证; 考虑到在项目的后期有部分__人员会在现场进行__,因此在网络条件上需要提供对远程访问方式的支持; 配置管理服务器的选择和配置管理软件的选择相关,考虑到目前公司有一台闲置的PC服务器,最好能充分利用这台服务器; 配置管理软件必须可以以某种方式支持远程访问,而且由于我们的__平台涉及Solaris和Windows,配置管理软件要能够支持这两种平台;考虑到__工具方面,配置管理工具要求能和我们选择的__工具进行很好的集成; 项目组的__人员缺乏使用配置管理工具的经验,有将约30%的__人员使用过VSS配置管理工具,但仅限于最基础的使用,对VSS的Label等功能没有概念;结合以上的情况,我们首先考虑配置工具的选择 配置管理工具的选择 软硬件环境的选择 确定了配置管理工具后,我们使用公司购置的一台CompaqPCServer作为配置管理的硬件环境,该服务器配置如下 CPU1CPU,P
42.0G 内存512MDDR 硬盘空间30G×4 网卡HPGbit网卡一张 最终确定的方案是__该服务器__Windows2000Server操作系统,为了保证配置数据的安全性,我们采用RAID0+1方式,总的可用空间在50G左右;另外为了备份的需要,还为服务器配置了一个CDR刻录机 网络环境的选择 公司已有现成的100M局域网,通过一个交换机和路由器连接至Internet,有一个公网的静态IP;配置管理服务器是内网的一台机器,具有一个内网IP为了满足远程访问的需要,我们通过在路由器上设置端口映射,将SOS需要使用的端口映射到配置管理服务器上(缺省情况下,SOS使用8888和8__0两个端口) 网络拓扑图如下 在公司的__人员通过局域网使用VSS访问和操作配置库,在现场的__人员通过Internet接入对配置库进行访问和操作 配置库维护和备份计划 配置库的维护的备份需要专职的配置库___来负责在整个项目中我们采用的配置库维护策略是根据Microsoft的BestPracti_____建议,包括以下要点
1、保持配置数据库的大小不超过5G;Microsoft建议,配置库的大小在3-5G比较合适,太大的数据库会极大影响VSS的效率;减小配置库大小的
2、每周进行VSS数据库的分析(____ysis),发现问题及时修正;VSS提供了____ysis和Fix工具,由于不合理的Delete等操作,VSS数据库有可能会出现一些InterruptData之类的问题,通过定期的每周的分析工作,可以极大减少数据库出现问题的风险;
3、每日进行配置库的增量备份,每周进行数据库的完全备份;VSS库的备份可以通过VSS自己的Archive功能或者是操作系统的Backup程序来进行VSS的Archive功能对VSS中的文件数据进行压缩并保留VSS的所有状态,但只能对VSS库进行完全备份,不能实现增量备份功能Windows2000Server提供的Backup实用程序可以对文件进行备份,由于VSS库就是以文件形势存在的,因此针对VSS的data目录进行备份也可以完全达到备份的目的,使用系统备份工具的好处是可以实现增量备份我们在实际中使用的系统的备份工具,每周五生成的完全备份采用刻录光盘的方式保存,每天的增量备份数据存放在文件服务器上进行备份 【小结】在本章中,我们描述了工程型项目配置管理的一些概念,着重介绍了配置管理的环境,包括配置管理工具的选择等在配置工具选择方面,我们采用VSS+SOS的组合方案,第二章中,我们将重点介绍VSS和SOS工具的使用,并在介绍配置管理规范中结合配置管理工具讲解具体的操作 说起VSS,接触过的人应该不少尤其是用用VC和VB做__的人,绝大多数人应该都接触过和使用过VSSVSS小巧精干,和VS__工具集成极为紧密,就算不使用专门的配置服务器,直接在自己的__用机上__一个VSS,也能在代码管理方面方便不少SOS在上一章中已经做了介绍,这一章将详细介绍之 VSS概念 也许正因为VSS简单易用,在大多数人眼里,VSS似乎都只是一个玩具,难登大雅之堂,最多能管管自己的代码,要用团队__中,那似乎是不可能的刚接触VSS时,我也是抱着差不多的想法,觉得要用VSS作为一个较大的项目的配置管理工具完全不可能,但随着对VSS研究的深入,加上在工作中也使用了其它一些配置管理工具,如CVS、ClearCase、CCCharvest等工具,反过来比较,反而觉得VSS有它独到的地方关于VSS和其他配置工具的比较,在google上搜索的话应该能找到一大堆,我这里给出几个对我来说印象最深刻的VSS的优势
1、VSS操作使用简单;要在配置管理工具中评选“最平易近人奖”,那一定非VSS莫属VSS中包含了配置管理需要的全部操作,但应用起来却非常简单,首先是全部操作都可以通过GUI完成,如CheckIn/CheckOut操作、GetLatest等基本操作;Label、Share、Branch、Merge等高级操作;其次是VSS和__环境集成紧密,在__环境的IDE中就可以方便地完成操作;
2、VSS对硬件配置要求不高;作为一个工作组级别的配置管理工具,在我们的项目中,__VSS的配置服务器是一台P
42.2G/512MRAM/30G×4Disk的HPPC服务器,这样的条件下VSS运行已经足够稳定和快速,相比起CC和CCCharvest的要求,这部分的投资是很小的;如果再考虑到CC和CCC都运行在Unix平台上需要的维护费用,当然是VSS更加划算了;
3、VSS几乎是免费的;只要__了VS__工具,就能____VSS;
4、VSS备份/恢复非常简单;只需要通过拷贝——覆盖就能完成VSS的备份/恢复工作,你说简不简单?)
5、有良好的可扩展性;通过VSS的自动化接口(Auto__tion),可以自己写程序来完成对VSS库的访问,也正是基于这点,目前市面上已有一些VSS的扩展工具出现,我们在本章要讲的就是其中之一——Sour__gear的SOS 说了这么多优点,当然不是说VSS就只有优点,和其他的配置管理软件比起来,VSS也有一些不足之处主要表现在以下几点
1、缺乏对Unix的支持(没有Unix上的客户端或者服务器,这是微软的一贯作风);
2、不支持远程访问方式(只能通过第三方的扩展工具实现);
3、支持的配置数据库大小建议不超过5G SOS(Sour__OffSite)软件介绍 接下来,我们重点介绍SOS软件,包括软件的__、配置和使用 SOS软件的__ SOS软件分为服务端和客户端两个部分,客户端运行在配置管理服务器上,客户端运行在需要访问配置库的客户机上以下以SOS标准版的SOS为例,说明该软件的__、配置和使用 服务端的__和设置 SOS可以从Sour__gear的__上下载试用,免费版本可以试用30天,允许10个用户,目前最新版本是
4.0不过为了解决SOS中的中文问题,建议大家从华军软件园中找到中文SOS进行__(所谓的中文SOS是国内的高手修改了SOS
3.53程序使其支持中文) 上图是中文SOS__时的__界面,选择__目录等,一路Next,很容易就__完成了__完成后,系统在“开始”菜单中生成了中文SOS的相关菜单项目 下图是__完成中文SOS之后生成的菜单 __完成后,需要对SOS进行设置选择中文SOS菜单的“服务器管理”进入设置界面 “SystemInfo”页面显示的是SOS的概要信息; “GeneralSetting”页包含了重要的设置信息,选中“useunsecureport”表示允许使用非加密模式进行数据传输,端口号在后面的编辑框中设置;选中“usesecureport”表示允许使用加密模式进行数据传输,端口号在后面的编辑框设置“Version
2.0Compatibility”用来选择加密模式,一般选择128bit模式即可在“Logging”选项中,选择日志的记录方式;最后的“IdleConnections”,如果选中的话,在指定时间内没有数据传输的话,连接就会自动断开 “SerialNumber”页面用来管理SOS的li__nse通过Add…按钮可以增加新的SerialNumberSOS中可以添加多个SerialNumber “Databases”页面用来添加SOS管理的VSS数据库__Add…按钮可以添加数据库,添加对话框的上一个框填入VSS库的ini文件所在路径,下一个是数据库的别名,可以任意设置SOS可以同时管理多个数据库1”“UserKeys”页面用来生成客户端访问控制的Key文件 使用“AddKey…”按钮可以弹出“AddUserKey”的对话框该对话框的第一个输入框要求输入要增加的用户在VSS中对应的用户名;第二个输入框要求输入SOS服务器的IP地址,例如“
202.
100.
68.88”,在局域网中可以设置为“
192.
168.
1.1”;(注意,如果配置管理服务器同时具有局域网和广域网的IP地址,并且用户需要从局域网和广域网都可以访问SOS,则对同一个用户需要两个不同的Key文件在我们的实际工作中,我们只使用SOS进行Internet上的访问,在局域网内还是使用VSS,因此没有这个问题)下面的Expiration要求输入用户的过期有效时间期限,选择“KeyNeverExpired”允许用户永不过期 输入完相应信息后,__“OK”确认生成用户Key文件生成的用户Key文件保存在SOS__目录下,文件名为[用户名].iky,注意保留此文件,SOS客户端在启动时需要首先导入一个key文件 “WebProject”页面用于设置WebProject的发布路径 在第一个编辑框中填入该工程在VSS中的路径,例如“$/WebProject1/test”,在下面的编辑框中输入发布的路径,例如“d:\temp”发布路径也可以是在其他机器上的网络路径 “Debug”页面是两个调试级别的选项 这两个选项的具体含义在SOS的__nual中也没有明确提到,我们在实际运用中也没有发现该选项的具体作用,建议不选取 “ExcludedFileTypes”页面设置不允许添加到VSS库中的文件类型添加的条目是文件后缀,具有在列表中的后缀的文件都不能被添加到VSS库中 “PinSupport”页面用于设置是否允许PIN操作 如果允许“PIN”操作,还需要指定ss.exe文件所在的目录 设置完成后,需要重新启动SOS服务端,具体方法是在“服务”中启动相应服务启动服务完成后,服务端的__设置就已经完成了,接下来我们介绍SOS客户端的__和使用 SOS客户端的__和使用 SOS的客户端分为Windows版本、Solaris版本和Linux版本Windows版本的__非常简单,直接执行__程序就可以顺利__Solaris版本的SOS客户端以tar形式发布,首先在Solaris上__GTK和GLIB,然后展开__程序到任意目录即可对Linux版本的SOS客户端,也需要首先__GTK和GLIB,然后展开相应tar包到任意目录即可 Solaris、Linux和Windows版本的SOS客户端运行界面都非常类似,下面以Windows版本为例说明其使用 第一次运行SOS客户端时,系统会弹出一个对话框要求输入服务器和端口号这时用“Can__l”按钮取消,选择菜单项的“Tools”——“ImportEncryptionKey…”,导入服务端生成的Key文件 导入完成后,选择菜单项的“File”——“ConnecttoServer…”,输入服务器IP地址和端口,如果连接成功,系统会给出可以连接的数据库列表,可以从列表中选择合适的数据库进行连接访问 连接成功后,显示的主界面和VSS的基本一致,SOS的操作方式和VSS的也一样,具体可以参见VSS的文档 下图是SOS的主界面 当然,SOS在操作上也有一些和VSS不同的地方,下面列出这些不同点
1、缺省设置下,SOS中每次登录不会主动刷新工程树和文件列表,需要用工具条上的刷新按钮进行刷新;
2、SOS的“Search”功能较VSS弱,只能查找CheckOut的文件;
3、SOS的Option设置项目很多,大部分都是SOS增加的为适应远程连接的设置项 【小结】本章介绍了VSS、SOS的使用,重点是SOS的__和使用方法SOS在使用上其实还有很多小技巧,在此不能一一列举,在sour__gear的__上都能找到相关的资料在下一章中,我们将结合配置管理工具介绍配置管理规范的内容配置管理规范 对于一个一般的项目来说,配置管理规范的内容至少需要包括以下的内容
1、配置项及其命名规则;
2、配置库文件目录结构;
3、角色和权限定义;
4、配置项变更流程;
5、配置项发布;
6、基线定义和基线变更 配置项及其命名规则 对我们的项目来说,配置项需要包括以下的内容
1、项目管理过程文档; a项目任务书; b项目计划; c项目周报; d个人日报和周报; e项目会议纪要; f培训记录和培训文档;
2、QA过程文档; aQA不符合报告; bQA周报; c评审记录;
3、工作产品 a需求文档; b设计文档; c代码; d测试文档; e软件说明书和手册;
4、项目中使用的第三方产品 上文中用红色部分标识的是容易遗漏的配置项,尤其是第4个(项目中使用的第三方产品),实际上,一个工程型的项目会大量使用第三方的软件(例如,我们的产品中就使用了IBM的MQSeries、Oracle、一些第三方的__控件),对这些产品的管理至少可以解决三个方面的问题
1、版本配合的问题大部分的第三方软件在升级之后,并不能实现二进制层面上的兼容,需要对原有的代码重新编译;甚至有的第三方软件在升级之后,API层面上的兼容性都做不到;因此,在工程实施的过程中,版本的配合问题是一个需要__的问题;
2、发布的完整性问题一般来说,比较大型的第三方软件在发布过程中都不会有遗漏,但对一些小的第三方软件来说,比如我们使用的许多perl的CPan模块,如果在__过程中没有有意识的进行管理的话,很容易就会发生遗漏;
3、在某些特殊条件下由于第三方软件的变化引起的基线变更这种情况极少会发生,但在我们以前的项目中,确实还遇见过一般是因为原来选型时使用的第三方软件不能满足要求,只能通过更换新的第三方软件,这就补课避免地需要变更基线(例如需求文档、设计文档等);将第三方软件纳入配置管理的范畴可以更方便地管理基线的变更关于第三方软件产品配置项的管理还有一点需要说明由于第三方软件有可能会比较大,而且相对我们的项目来说,是很少会发生变更的(一般在一个项目过程中,不会采用不同的配置项的命名可以便于查找相关配置项配置项的命名包括两个方面的内容
1、配置项标识在我们的项目中,一般使用“项目名_配置类别_配置项特殊标识”来命名下表列出了我们在项目中使用的配置类别命名配置类别命名配置类别命名项目任务书PT项目计划PP项目周报PR个人日报和周报PER项目会议纪要PM培训记录和培训文档TRQA不符合报告QAPQA周报QAR评审记录RR需求文档REQ设计文档DD代码CODE测试文档TD软件说明书和手册__N项目中使用的第三方产品PART3 配置项命名中的“配置项特殊标识”根据配置类别的不同而不同比如,对“设计文档”,如果细分的话,可以分为“概要设计”和“详细设计”;对“代码”,可以按照模块来命名配置项
2、配置项版本命名配置项版本命名是针对配置项的版本进行命名,在我们的项目中,配置项版本通过对Project的Label操作来实现,配置项版本的命名需要能清楚标识配置项的状态一般说来,配置库至少包括个人工作区、受控库、发布区三个部分,在我们的项目中,所有的配置项都保存在一个VSS库中,对这三个部分的划分是通过逻辑划分方式进行的,具体来说,就是通过配置项版本命名来划分的因此,我们配置项的版本命名规定如下 a基线版本按照基线的状态,我们这个项目中的基线有两个方面一是作为里程碑的基线;另一个是模块的阶段性成果基线(对工作产品而言),由模块的负责人确定 里程碑基线――对我们的项目来说,采用的是迭代的__过程,以一个迭代过程为例,分为需求、概要设计、详细设计、代码实现、单元测试、集成测试、系统测试七个阶段,每个阶段都需要产生里程碑对每个里程碑都有明确的标识标明当前状态 阶段性成果基线――阶段性成果主要体现在代码过程中,比如代码进行到一个阶段,__组长认为代码的这个状态可以保留,就可以确定为一个代码基线这种基线一般不需要通过评审等正式手段来确定,但也必须有相应的验证手段;比如在我们的项目中,在代码阶段,确定代码基线的责任人是__组长,但__组长必须保证代码基线符合一定的条件 b其他版本除基线版本外,有时候还需要在__和维护过程中确定其他版本例如,产品在测试过程中不断的问题修复过程中,可能会有多种反复,此时需要将每次修改的内容作为一个版本 关于版本,还有另一个需要注意的问题一般来说,按照模块来划分,每个模块有自己的版本演进比较合理首先,一个模块一般是由一个或两个__人员完成的;其次,一个模块的功能会比较单一且__,在版本的演化过程中便于控制,也不会和其他模块产生过于复杂的关系而产品的版本则需要由各个模块的不同版本组成,这个纵横的关系需要很好地管理,我们的做法是在VSS库上用Label来标识,同时维护一张描述产品版本和模块版本关系的矩阵图便于追踪 配置库目录结构 在确定了配置项之后,就可以确定配置库的目录结构了配置库的目录结构直接关系到配置管理的工作量和使用的方便性,所以需要根据自己的需要确定一个合理的结构 在确定配置管理库目录结构的时候,我们曾经考虑过两种产品目录结构的方式一种是按照模块划分,在模块下再划分诸如设计文档、代码等目录;另一种方式是按照产品类型划分,例如首先是文档、代码,然后在其下按照模块划分这两种方式都有自己的优点,最终我们还是选择了前一种划分方式,一方面是考虑便于进行权限的分配,另一方面是考虑到便于将同一模块的所有内容组织起来进行版本的管理 下表是我们在实际中采用的配置库结构(部分)第一级第二级第三级第四级说明M 管理类文档 PM 项目管理 0-Init 初始阶段 PC PTR PN 1-Plan 计划阶段………………………… QA 0-PPQAP 质量保证计划…………………………P 项目产品 0-Req 需求阶段 0-CRS 客户需求 1-SRS 需求分析文档 2-RTM 需求跟踪矩阵 1-Des 设计阶段 0-HLD 概要设计 1-DBD 数据库设计 2-Imp 实现/编码阶段 0-Module1 模块1 0-COD代码 1-DDS详细设计 2-HLD概要设计 3-UNT单元测试………………………… 3-Test 0-Int 集成测试 1-Syt 系统测试………………………… 4-__n 手册………………………… 5-Others 其他………………………… 从这里的配置库结构中可以看到,我们在最上层将配置项分为管理类和产品类管理类中的项目管理部分基本是按照初始-计划-执行-收尾四个阶段来划分在项目产品类别中,我们按照需求-设计-实现-测试四个阶段划分目录,在实现阶段,为每个模块划分了代码、详细设计、概要设计和单元测试四个目录,需要说明的是,在第三层中有一个HLD的目录,在模块下同样有一个HLD的目录,在我们的实际工作中,第三层的HLD目录用来存放系统级别的概要设计文档,而模块下的HLD目录用来存放模块级别的概要设计文档当然,这里的配置库结构仅仅起到了示范作用,在实际使用中,可以根据自己的需要修改例如,在Module的级别上可以增加一个SubSystem的层,便于在产品集成时更加方便 角色定义及权限分配 角色是配置管理流程的执行者和参与者,定义明确的角色有利于实现明确的授权和明晰的流程,虽然在实际中可能多个角色由一个人担任,但还是应该保留角色的定义 下面是该项目中我们的角色定义 配置___ 整个配置管理库由配置___管理配置___负责分配和修改其他成员的权限,要维护所有目录和配置项 __经理 __经理在本项目中负责主导完成需求分析和系统总体设计,对项目的总体进度负责__经理拥有对管理类文档的读取权限,可以对项目类文档进行读写操作; __组长 __组长对本小组的工作负有组织和管理任务,同时__组长也需要承担一定的__任务__组长对管理类文档有读取权限,对本组负责的模块有读取权限,对自己负责的模块有读写的权限; __工程师 __工程师完成具体的__任务,对自己负责的模块目录有读写权限,对管理类文档有读取权限; 测试组长 测试组长负责组织测试,给出测试计划和测试方案,并核定测试报告测试组长对所有目录都有读取权限,对测试目录有读写权限; 测试工程师测试工程师负责完成测试工作,包括测试用例__和测试执行,测试报告编写测试工程师对自己负责的模块有读取权限,对测试用例目录有读写权限 QA工程师QA工程师拥有对所有目录的读取权限,拥有对QA类文档目录的读写权限〔说明〕除配置___外,其他所有成员都没有Destroy目录和文件的权限,这是为了防止误删除操作带来不可挽回的损失如果需要对目录进行Destroy操作,必须由配置___进行【小结】在本章中,我们介绍了配置管理规范的配置项及其命名、配置库的目录结构以及配置管理的角色权限分配在下一章中,我们将介绍完配置管理规范的其他内容并给出配置管理实施过程中的一些心得体会配置项变更流程 我们所说的配置项变更流程主要是针对配置项发生变化的控制,在我们的项目中分为两个部分,首先是对配置项新建、检入(CheckIn)和检出(CheckOut)的规定;其次是对入库的文件类型和大小的规定 新建、检入、检出及破坏
1、新建即Add,除特殊情况外,一般不规定由谁来新建(只要有权限即可),但尽量指定每个project只有一人负责新建
2、检入即checkin,检入频率规定如下 i.在代码编写前,至少每周一次 ii.代码编写阶段,至少每天一次 iii.测试阶段以后,根据代码、文档的变动,只要当天有变动就要检入一次 iv.为配合检查、备份工作,需在检查备份周期前全部checkin不保持checkout并退出登录详见“检查及备份”部分
3、检出即checkout原则上只对要修改的文档方可检出
4、破坏(Destroy)一般情况不可以破坏文件、目录
5、如果是误操作,则可在一天内提交___处
6、如果超过一天,则需要由项目经理同意,且___破坏前要备份
7、各阶段环境职责环境阶段负责人职责公司内部编码前__人员每周及需要评审前checkin工作产品(包括版本发布说明)到VSS上__组长每周SCM人员每周统计编码__人员每天checkin工作产品(包括版本发布说明)到vss上__组长每周检查经理及组长抽查及走读SCM人员每周统计,检查代码风格测试__人员每天checkin工作产品到vss上(如当天没有修改可以不进行checkin)以LABEL形式提交一个新版本给测试,附带版本发布说明测试人员对测试完成后的程序打LABEL发布后__人员将新版本checkin到vss打测试LABEL向测试人员提交申请测试人员对测试完成后的程序打LABELSCM人员对变更做好控制和记录,并发布现场__负责人将发布后的产版本更新至现场,或指定人员进行公司外部编码现场__负责人在无法通过sos连到公司vss的情况下,需要在现场建立配置库(文件方式或VSS等),做到基本的版本控制和备份每周至少通过SOS提交一次至公司的VSS库中现场__人员每天checkin工作产品到现场配置库(包括版本发布说明)SCM人员做好督促和监督工作,每周将现场__负责人提交的现场版本更新到公司配置库(vss)测试现场__人员每天checkin工作产品到现场配置库(如当天没有修改可以不进行checkin)如已经回公司则每天checkin工作产品到公司配置库vss(如当天没有修改可以不进行checkin)每周通过SOS提交一个新版本给测试,打测试LABEL附带版本发布说明如没有更新可不提交对测试完成后的程序打LABELSCM人员做好督促和监督工作发布后现场调试现场维护现场__负责人在无法通过sos连到公司vss的情况下,需要在现场建立配置库(文件方式或VSS等),做到基本的版本控制和备份每周至少通过SOS提交一次至公司的VSS库中通过LABEL提交测试版本现场__人员对修改后的版本通过SOScheckin新版本到vss打测试LABEL向测试人员提交申请(由修改至提交测试人员不应超过三天)测试人员对测试完成后的程序打LABELSCM人员对变更做好控制和记录,并发布做好督促和监督现场提交更新版本到vss 关于VSS库内存放文件类型及大小的规定
1、文件名及目录规定以英文名字命名
2、文件大小规定最大不超过20M
3、允许类型
4、表
2.1中提至的文档类
5、代码及脚本类及为配合编译需要的类库等
6、以下类型不允许存放在VSS库中
7、备份数据
8、__程序、打包程序(zip\rar)
9、超过20M以上的非代码类及__文档类文件
10、对于特殊情况或不确定情况,需向配置管理人员__后再加入
11、对于不允许存放类型的配置类文件,可与配置___联络,随件附《说明清单》,以文件型式保存于服务器 配置项发布 配置项发布是指配置项进行到一定的阶段(例如,里程碑阶段),需要对外发布时的规则在我们的项目中,配置项发布是通过标签,即LABEL,来实现的阶段触发__操作人标签类型打标签的级别单元测试单元测试完成,可以提交集成测试__人员FOR_TEST模块级集成测试集成测试完成,不通过(如通过进入系统测试阶段)测试人员TESTED模块级BUG修改完成,可以提交测试__人员FOR_TEST模块级集成测试通过,可以提交系统测试测试负责人TESTED模块级系统测试系统测试完成后,不通过,(如通过进入系统测试阶段)测试负责人TESTED项目级BUG修改完成,可以提交测试__人员FOR_TEST项目级系统测试通过测试负责人TESTED项目级验收测试验收前的版本,可发布到现场__配置___LOAD项目级验收后的版本,可发布的正式版本配置___LOAD项目级现场维护修改BUG后提交测试维护工程师FOR_TEST模块级/项目级/文件级测试通过与否测试人员TESTED模块级/项目级/文件级 基线确立与变更 基线的确定在上一部分中已经说到过,我们的项目基线分为两类,一类是作为里程碑和其他工作依赖的基线(例如需求文档、设计文档等),另一类是__过程中有必要保留的一种状态(例如代码过程中某个模块的一个有保留价值的snapshot)对这两种不同的基线,其影响的范围不同,确立和变更方式也不一样 我们项目的基线变更控制委员会由客户代表、产品经理、项目经理以及技术经理组成,对发布的里程碑类基线的变更必须由变更控制委员会确认并由QA进行变更记录,所有被变更影响的配置项都需要重新同步后再次发布;而对于仅仅作为工作状态保留的基线,一般只需要建立基线的小组确认更改并在QA进行记录即可 检查与备份
1、检查 根据VSS___建议,要定期检查数据的正确性故VSS库___应每周检查一次,流程如下 a__人员于每周五下午5:30前checkin(不保持checkout)并退出登录 bVSS库管理人员用____yze工具检查VSS数据库,操作如下 在dos命令行中输入____yze–f–d–c–v4c:\vss\data 其中“c:\vss\data”为vss库的数据目录
2、备份 a每天增量备份,通过windowsNT以上自带的备份工具进行增量备份,备份以硬盘存放即可 b每周全备份每周检查完毕之后,对VSS数据库进行全备份,建议以光盘介质备份 配置管理实施后记 应该说,这次我们对项目的配置管理实施是非常成功的,在整个__过程中,基本没有出现因为配置管理的问题导致的对__进度的延误当然,在__过程中也发生了由于需求变化导致基线变更引起__进度的延迟,不过这不应该算作是配置管理的失误,因为作为配置管理来说,只能尽量保证基线变更不会导致项目失控 总结我们这次的配置管理实施工作,除了这几篇文章中讲到的需要注意的问题外,我觉得有一些应该算做是决定实施成败的关键因素
1、一个好的执行人员是成功的关键; 一个好的执行人员的重要性怎么强调都不过分所谓的一个好的执行人员应该具备这样的素质 a对配置管理工作有较为深刻的理解; b对使用的配置管理工具运用熟练; c具有好的沟通能力,能和__组长、__人员以及其他干系人沟通; d有好的执行力,对流程的执行能起到监督和推动作用; e耐心细致,很多时候,细节决定了成败;
2、好的工具能起到事半功倍的效果; 选择一个合适的配置管理工具绝对是必要的,我们在前面用了一章多的篇幅介绍我们使用的配置管理工具及其方案,事实证明,我们选择的配置管理工具对我们项目管理实施的效果是决定性的
3、在配置管理实施的初期,及时的指导起的作用是巨大的,甚至可以说是成功的主要因素; 对不熟悉配置管理的__工程师来说,配置管理工作容易在一开始就让他们产生厌烦情绪,一点点使用上的不方便就会导致__人员对配置管理的怨言,这个时候,及时的指导就显得非常重要了,我们在配置管理实施过程中,准备了《VSS操作手册》、《SOS简明操作手册》、《配置管理操作指导书》等手册,进行了三次的培训,并在实施过程中随时解决__人员在使用配置管理工具中的问题而且,在实施初期,我们以奖励为主,在一个月的时间内没有将配置管理工作作为考核内容
4、每周的配置状态检查非常重要; 在配置管理基本走上正规后,每周的配置状态检查是我们对配置管理执行效果的检查,一旦发现问题,会作为QA问题报告发出并要求限期改正如果没有这个检查制度,配置管理工作很难持续受控 〔后记〕 《工程型软件项目配置管理实例》这几篇文章是我们在项目的配置管理实施过程中的一些体会,和其他配置管理文章不同的是,这里我们给出的都是马上就可以应用的实践步骤当然,每个公司的环境各有不同,同样的实践不可能在每个地方都能产生一样的效果,只是希望这一系列文章能给大家一些启发 时间仓促,文章中有些地方可能还有未能表达清楚的地方,欢迎大家和我探讨。