配置管理制度合集

精品文档精心整理精品文档可编辑的精品文档配置管理制度合集目录：1、DotNET项目编译指南2、基线建立控制报告3、服务器部署的关键因素4、系统基线建立控制报告5、置管理工作指南6、软件交付平台用户手册文件编码文件密级最新发布日期当前版本DotNET项目编译指南。本文檔中任何部分未经XX软件股份有限公司书面授权，不得将材料泄露给第三方，不得以任何手段、任何形式进行复制与传播变更履历版本日期变更位置变更理由/变更内容变更人备注1.0新建1.1根据研发项目管理流程问题巡检检查出的问题进行更新：增加变更履历一、名词解释编译管理软件：公司内部开发的、用于编译管理系统。可以对不同权限的用户提供不同项目的编译服务。Helper工具：公司内部开发的编译辅助工具。可修改每个程序集的版本信息等。二、编译分类编译主要有两种编译选项：Debug：用于调试。保存了状态信息，方便调试。开发人员一般使用此设置。Release：用于生成最终的发布代码。给测试和实施人员发布程序时使用此设置。三、编译选项编译选择需重点关注如下几项，其它选项使用默认设置即可。应用程序项（图1）图1编译选项－－应用程序程序集名称（N）：生成的EXE或DLL文件名称。默认命名空间（L）：程序级的命名空间，其它应用调用时使用。输出类型（U）：Windows应用程序、控制台应用程序、类库。程序集信息（I）：包含了标题、说明、公司、产品、、商标、程序集版本、文件版本、GUID等信息（如图2）。图2程序集合信息图标（C）：应用程序图标。生成（图3）：条件编译符号（Y）：如果程序中需要条件编译则再次设置。如下编译指令#ifNET20privateList<Driver>m_inUsePool;privateQueue<Driver>m_idlePool;#else privateArrayListm_inUsePool; privateQueuem_idlePool;#endif如果在编译符号编辑框输入NET20，则实际编译时使用如下定义privateList<Driver>m_inUsePool;privateQueue<Driver>m_idlePool;否则使用另一种定义。将警告视为错误：无表示处理警告；特定警告表示对指定的警告视为错误，不能通过编译；所有则表示编译时不允许有警告，否则编译不通过。输出路径（O）：程序集生成的路径，可以是相对路径（默认bin\Debug\）也可以是绝对路径。XML文档文件（X）：选中该复选框生成时将同时生成程序的XML说明文档，该文档可以通过其它工具生成html格式的技术文档。图3编译选项－－生成生成事件：使用默认设置调试：使用默认设置资源：使用默认设置设置：使用默认设置应用路径：使用默认设置签名：为程序集签名（A）：选中该复选框后，可以选择强名称密钥文件（如图4）。如果强名称密钥文件不存在时可以新建（如图5）。图4编译选项－－签名图5编译选项－－签名－－创建强名称密钥代码分析：使用默认设置OCX使用：注册OCX：在开始/运行窗口输入“regsvr32+OCX路径”注册OCX控件。如regsvr32E:\DEV\CI_GOV_YKT\04源代码\05表格打印组件\JQPrintXControl.ocx将OCX添加到开发环境中：启动MicrosoftVisualStudio2005开发环境，从菜单栏选择工具/选择工具箱项（如图6），在选择工具箱项窗口切换标签页到COM组件，在COM组件列表找到已注册的OCX控件并选中，点击确定即可（如图7）。如果列表中不存在可通过“浏览”按钮从文件中选择。图6选择工具箱项图7添加COM组件四、手动编译添加引用在编译前应确保该项目说引用的程序集引用都已添加。添加引用的方式为，展开项目找到引用节点，右键单击引用并选择“添加引用”菜单（如图8）。打开添加引用窗口（如图9），选择要引用的文件包括自带的程序集、COM组件、项目和自定义程序集等。如果选择了项目，则编译该项目前系统会先编译其所依赖的其它项目。图8添加引用图9添加引用窗口生成生成当个项目：选择要编译的项目，单击右键选择“生成”或“重新生成”菜单图10生成单个项目生成整个解决方案：在开发界面菜单中选择生成/生成解决方案菜单即可。图10生成解决方案注意事项如果OCX重新注册，则需要先对清理再生成，或者选择重新编译菜单。五、自动编译原理自动编译就是将编译过程做成批处理文件，通过执行批处理文件便可完成更个编译过程。编译过程需要解决如下几个问题。版本自动生成（生成规则见附录A）：每个程序集（EXE或DLL）文件都可以有自己的版本，版本信息存放在每个项目中的AssemblyInfo.cs文件中，因此编译时只需要修改AssemblyInfo.cs文件中相应的信息即生成所需的版本。我们是通过公司内部的helper小程序实现。OCX控件自动注册：可使用regsvr32实现。参数“-s”表示注册OCX控件，参数“-u–s”表示取消注册。编译：利用自带的devenv工具可以实现用命令的方式编译。错误处理：当发生编译错误时应将错误信息写入日志文件。步骤1、设置环境变量PATH=C:\ProgramFiles(x86)\MicrosoftVisualStudio8\Common7\IDE;C:\ProgramFiles(x86)\WinRAR;C:\ProgramFiles(x86)\Borland\StarTeamCross-PlatformClient2008;D:\Projects\ci_gov_ykt1.0\build;%PATH%;2、设置目标文件夹路径setDestDir=D:\Projects\ci_gov_ykt_client1.0\out\3、获取源文件到文件编译目录（如果文件编译目录中已存在源文件则应先删除）stcmdco-p"用户名:密码@10.2.9.250:49201/CI_GOV_YKT/CI_GOV_YKT/04源代码/02客户端/"-o-is-fp"D:\Projects\ci_gov_ykt_client1.0\source\"4、获取OCX文件stcmdco-p"sun:zhangxuewen@10.2.9.250:49201/CI_GOV_YKT/CI_GOV_YKT/04源代码/05表格打印组件/"-o-is-fp"D:\Projects\ci_gov_ykt_client1.0\source\ocx"5、注册OCX控件regsvr32-u-sD:\Projects\ci_gov_ykt_client1.0\source\ocx\JQGrid.ocxregsvr32-sD:\Projects\ci_gov_ykt_client1.0\source\ocx\JQGrid.ocxregsvr32-u-sD:\Projects\ci_gov_ykt_client1.0\source\ocx\JQPrintXControl.ocxregsvr32-sD:\Projects\ci_gov_ykt_client1.0\source\ocx\JQPrintXControl.ocxregsvr32-u-sD:\Projects\ci_gov_ykt_client1.0\source\ocx\JQImportXControl.ocxregsvr32-sD:\Projects\ci_gov_ykt_client1.0\source\ocx\JQImportXControl.ocx6、设置年、月、日、时、分变量，这些变量的值有外部程序helper提供helperget-yifnoterrorlevel0gotodirerrorsetYear=%errorlevel%7、设置生成目标文件夹名称。（文件夹名称格式：yyyy-mm-dd-hh.mm）setDestDir=%DestDir%%year%-%month%-%day%-%hour%.%minute%\8、创建Release路径setReleaseDir=%DestDir%release\9、创建日志路径setLogDir=%DestDir%log\10、修改程序集版本号（如果一个项目有多个程序集是需分别改写）。改写版本号的功能有外部程序helper提供ifexistD:\Projects\ci_gov_ykt_client1.0\source\Jiuqi\YKT\mkdirD:\Projects\ci_gov_ykt_client1.0\source\Jiuqi\YKT\helperwriteverD:\Projects\ci_gov_ykt_client1.0\source\Jiuqi\YKT\AssemblyInfo.cs11、编译devenvD:\Projects\ci_gov_ykt_client1.0\source\JIuqi\YKT\JQYKT.sln/rebuild"Release">%LogDir%build.log12、错误处理ifnotexistD:\Projects\ci_gov_ykt_client1.0\source\Jiuqi\YKT\bin\Release\JQYKT.exegotobuilderrorcopyD:\Projects\ci_gov_ykt_client1.0\source\Jiuqi\YKT\bin\Release\*.*%ReleaseDir%gotoover:direrrorecho创建目标文件夹失败:builderrorecho编译失败，应该与研发负责人联系，解决编译错误的问题:over使用方法编译过程测试人员使用编译管理软件向编译服务器发送编译请求。如图编译过程中的①。编译服务器从StarTeam服务获取要编译的文件。如图编译过程中的②、③。编译服务修改源文件版本信息，并生成程序集和日志文件。如图编译过程中的④从编译服务获得可执行文件。附录：A版本号生成规则如果整个程序有大的调整，有了很大的改观就升级大版本号，如可以从1.0变成2.0如果是按阶段发布版本，就可以改小数位第一位，如：1.1、1.2、1.3……如果是阶段内每天有改动，可以在后面加上年份和日期，年份从今年开始递加如：1.0.00807，如果是明年的1月21日则是：1.0.10121最后一位表示当天的改动次数，如第一次改动版本号是：1.0.00807.1，第二次改动是：1.0.00807.2每个动态库或exe文件都应有独立的版本信息。附录BVista上注册OCX的方法一、UAC说明UAC(UserAccountControl:用户帐户控制)是微软为提高系统安全而在WindowsVista中引入的新技术，它要求所有用户在标准账号模式下运行程序和任务，阻止未认证的程序安装，并阻止标准用户进行不当的系统设置改变。可以防止恶意软件获取特权，就算用户是以管理员帐户登录也可以起到保护作用。二、手动方法：1、启动vista后，在‘开始’→‘运行’框中输入“msconfig”命令，点击‘确定’。（也可以通过‘开始’→‘管理工具’→‘系统配置’来打开系统配置对话框）2、在弹出的‘系统配置’对话框中，切换到‘工具’页签，拖动滚动条，找到并选择‘禁用UAC’选项，点击‘启动’按钮禁用UAC功能。3、点击‘确定’，重启计算机。4、计算机重新启动后，安装并注册OCX控件。5、所需OCX控件下载完毕后，重新打开‘系统配置’对话框，选择‘启用UAC’选项，点击‘启动’启动UAC功能。（此一步非常重要，一定要启动UAC功能，以保证vista操作系统的安全性）6、重启电脑。三、自动方法1、右键单击‘禁用UAC并重启电脑.bat’程序，选择‘以管理员身份运行’，按照提示完成后，等待电脑重启完毕，安装并注册OCX控件。2、运行‘启用UAC并重启电脑.bat’程序，进行UAC功能的开启和电脑的重启工作。四、禁用UAC并重启电脑bat文件内容@echoWindowsRegistryEditorVersion5.00>>UAC.reg@echo.>>UAC.reg@echo[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System]>>UAC.reg@echo"EnableLUA"=dword:00000000>>UAC.reg@ping127.0.0.1-n2>>null@regeditUAC.reg@delUAC.reg@delnull@echo是否重新启动电脑?@echo.@echo如果"是"请输入"y"并回车(推荐)，"否"请输入"n"并回车。@echo.@set/pv=请输入你的选择。[YorN]@if%v%==ygotocongqi@if%v%==ngototuichu:congqi@echo.@echo正在重启电脑...@ping127.0.0.1-n3>>null@delnull@shutdown-r@exit:tuichu@echo.@echoUAC功能已禁用，但是在重启电脑前不会生效!@echo.@pause五、启用UAC并重启电脑bat文件内容@echoWindowsRegistryEditorVersion5.00>>UAC.reg@echo.>>UAC.reg@echo[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System]>>UAC.reg@echo"EnableLUA"=dword:00000001>>UAC.reg@ping127.0.0.1-n2>>null@regeditUAC.reg@delUAC.reg@delnull@echo是否重新启动电脑?@echo.@echo如果"是"请输入"y"并回车(推荐)，"否"请输入"n"并回车。@echo.@set/pv=请输入你的选择。[YorN]@if%v%==ygotocongqi@if%v%==ngototuichu:congqi@echo.@echo正在重启电脑...@ping127.0.0.1-n3>>null@delnull@shutdown-r@exit:tuichu@echo.@echoUAC功能已禁用，但是在重启电脑前不会生效!@echo.@pause精品文档精心整理精品文档可编辑的精品文档基线建立控制报告基本信息项目编号项目名称申请日期申请人员配置管理员基线建立申请及审批基线名称设计基线基线版本1.0基线所包含的主要配置项需求规格说明书数据要求说明书项目开发计划品质保证计划配置管理计划系统体系结构设计说明书系统概要设计说明书需求规格说明书（内部）模块设计说明书项目测试计划建立原因及可能的影响设计阶段结束。无影响。建立申请人签字基线建立申请审批CCB审批意见同意！CCB负责人签字：日期：

基线建立报告本基线包含的主要配置项名称当前版本存放路径提交人需求规格说明书1.0\03需求\03需求确认数据要求说明书1.0\03需求\03需求确认项目开发计划1.1\01项目管理\02计划品质保证计划1.0\01项目管理\02计划配置管理计划1.1\01项目管理\02计划系统体系结构设计说明书1.0\04设计\02概要设计系统概要设计说明书1.0\04设计\02概要设计需求规格说明书（内部）1.0\04设计\01需求开发模块设计说明书1.0\04设计\02概要设计项目测试计划1.0\01项目管理\02计划结束申请CCB签字CCB负责人签字：日期：精品文档精心整理精品文档可编辑的精品文档StarTeam服务器部署的关键因素、服务器端组件部署策略根据StarTeam所支持团队的大小，需要采取不同的部署方案来保证StarTeam的性能及可靠性。存储库大小、并发用户数、是否部署StarTeamMPX、应用程序的复杂程度（指自定义表单、自定义字段等）等等，都会对StarTeam的性能产生影响。根据经验数据，团队的大小在一定程度上与project、view的数量成正比，而project、view的数量又决定了存储库中数据量，所以我们可以使用并发用户数来界定StarTeam配置库（ServerConfiguration）的大小。根据并发用户数多少把StarTeam配置库分为三种类型：小型配置库：并发用户数不超过50；中型配置库：并发用户数不超过100；大型配置库：并发用户数达到并超过100；一个服务器上部署多个配置库对于小型或中型的配置库，可以把所有的StarTeam服务器端组件（StarTeamServer、Database等）都部署到一台机器上。下图给出了相应的部署图。一台机器上所有配置库的并发用户之和不能超过100，但一台服务器的并发用户数的峰值到达100时，建议把服务器上的某个配置库迁移到另一台机器上。StarTeamServer相关的RootMessageBroker进程、RootCacheAgents进程、DatabaseServer进程以及所有的StarTeamServer进程都运行在一台机器上，因此对机器配置有以下要求：DatabaseServer进程需要分配一个CPU及1G内存；每增加一个StarTeam配置库需要分配一个CPU及1G内存；中型配置库当并发用户数达到中型配置库的标准时，首先需要为Database提供一个单独的机器安装。下图给出了相应的部署图。如图，除数据库独立外，其他进程仍然可以运行在同一台机器上。DatabaseServer进程占用的负载被转移后，允许的并发用户数可以到达200－300。然而对于有多个配置库的情况，vaults和databases会分布在不同磁盘上，不利于备份和管理，因此建议把需要备份的数据放到一个公用的磁盘上，如下图所示：大型配置库大型配置库是指可以支持100个以上并发用户的配置库。对于大型配置库，需要给每个StarTeamServer进程提供单独的机器，DatabaseServer进程也需要单独的机器支持，RootMessageBroker进程，RootCacheAgents进程最好也使用单独的机器（MPX）支持。特别是当并发用户数达到并超过200、300时，MPX进程运行在单独的机器上会很好的消除StarTeamServer上的网络阻塞和资源争用。下面给出了多个大型配置库的部署图：对于大型配置库的部署需要注意：每个StarTeamServer进程需要运行在一个单独的机器上，机器配置需要满足2CPU、2G内存用于支持100－200的并发用户，200个以上的并发用户需要4CPU、4G内存；如果预期用户数还会持续增加，推荐使用4CPU、4G内存；DatabaseServer进程需要运行在单独的机器上，多个StarTeam配置库可以共享一个DatabaseServer。StarTeamserver和DatabaseServer之间需要1G的高速网络连接。RootMessageBroker进程，RootCacheAgents进程可以运行在同一台机器上，称为MPX。每个CacheAgent需要访问相应的vault，此时高速网络连接并不是必须的，通过网络的文件访问就足够了。如果需要使用工作流NotificationAgent，也可以部署到这台机器上。所有的StarTeamvault和database使用一个公共的存储服务器管理。、影响服务器性能的因素对于StarTeam服务器端硬件的选择，需要考虑各方面的因素，例如，计划部署几个配置库（ServerConfiguration）、配置库中大概会有多少工作产品、预期的并发用户数、预期组织内项目及人员的增长情况等等。即使对这些因素有明确的的预期，在评估硬件需求的过程中也仅仅是估算，而不可能做到精确的计算。这是因为，配置库使用过程中会有一些不确定因素，例如文件大小、配置库增长情况、同时进行签出操作的并发用户数等等。正是因为有这些不确定因素，我们更需要了解StarTeam服务器端的各种服务对那种硬件资源的占用得更多。下面介绍StarTeam服务器端的各种服务对不同硬件资源的占用情况。StarTeamServer进程相关StarTeamServer进程对硬件资源的占用按重要级别排序依次为：内存StarTeamServer进程推荐的最小内存为256M。如果需要支持10－20个用户，内存必须达到512M；当并发用户数介于50－100之间时，必须有1－2G的内存支持StarTeamServer进程；而并发用户数超过200时，必须有2－4G内存支持。注意：对于32位的Windows操作系统，给一个进程分配的最大虚拟内存是2G，当2G内存都被使用的情况下，StarTeamServer进程可以把最大虚拟内存调至3G。CUPCPU的速度、一二级缓存大小等参数都会对StarTeamServer的性能产生影响，由于它是多总线的架构，多个CUP对提高StarTeamServer的性能有帮助。当预期并发用户数介于25－50之间时，可以考虑使用带有双核处理器的机器；当并发用户数介于50－100之间时，可以考虑使用带有四核处理器的机器。网络在并发操作较多的情况下，网络带宽对StarTeamServer的性能有较大影响。如果使用独立于StarTeamServer的数据库服务器，那么需要在这两台服务器之间提供100M-1G的内网带宽。当连接StarTeamServer服务器的客户端很多，且执行的操作，例如批量的文件签出操作，也相当多时，客户端和StarTeamServer服务器端的网络连接将称为瓶颈。带宽为100M的内网将足以支持100－200个并发用户，当并发用户数超过200时，需要考虑使用1G的带宽。事实上，所有的StarTeamServer进程都是处理到数据库和Vault的I/O操作，下面介绍数据库和Vault对硬件资源的占用情况。数据库相关数据库也是StarTeam服务器端的一部分，需要考虑数据库的配置、备份、收缩等操作。当需要考虑数据库硬件选择时，下面给出了一些参考意见：内存与StarTeamServer类似，数据库系统也是使用内存缓存机制来改进性能的。对于大型的StarTeam配置库，需要将数据库系统放到单独的服务器上，并使内存大小足以满足数据库服务的需要。磁盘阵列使用磁盘阵列会在很大程度上提高数据库I/O操作的性能，不同的RAID级别对性能改进和容错能力有不同程度的支持，可以考虑对数据库使用某种级别的磁盘阵列。CPU与StarTeamServer类似，数据库系统也支持多线程，使用速度更快，多个处理器的系统也会提高数据库系统的性能。网络前面提到过，如果有单独的数据库服务器，那么就要求在数据库服务器与StarTeamServer服务器之间使用高速的专线网络连接。Vault相关所有基于文件的操作都是针对Vault进行的，例如签入、签出操作，添加附件等等。Vault由Cache、Archive、Attachments组成，下面给出针对这几个部分的I/O操作：CacheCache是Vault中使用最频繁的部分，签入文件时会向cache中新增文件；签出时，如果cache中已经有这个文件就直接签出，如果没有这个文件，待签出文件会被添加到cache中。ArchiveArchive的使用频率仅次于Cache，每个文件在签入时，会向archive中新增文件，或者更新archive中已有的文件。文件签出时，如果在cache中没有找到相应的文件，就会访问archive中的文件。AttachmentsAttachment中的文件的使用频率更低，只有当通过CR、task、topic和requirement对象访问时，才会向Attachment文件夹中添加文件或读文件。注意避免将Cache和Archive安装到系统盘。如果数据库和StarTeamServer在同一台机器上，避免将数据库数据文件与Vault存储在一个盘。如果有多个磁盘，请将数据库、Cache、Archive和系统分布在不不同的磁盘，从而使允许的I/O并发数最大。如果对Vault采用RAID机制，会提高Cache和Archive的性能。但是，由于Cache中的数据来源于Archive，因此RAID的容错特性只对Archive有效。MPXMessageBroker相关MPX可以降低网络拥塞，即使是将MessageBroker与StarTeamServer进程部署到同一台机器上。但是在没有增加硬件的情况下，StarTeamMPX会使客户端相应时间和服务器端吞吐量有一定增涨。因为，MPXMessageBroker是独立的进程，可以通过把该进程与StarTeamServer进程部署到两台不同的服务器上来缓解网络拥塞。另外，MPXMessageBroker进程对所在服务器的要求并不高，内存大小和CPU数量对MessageBroker进程并没有影响。因为，MessageBroker进程只起通信服务器的作用，对内存和CPU的占用很少，而且几乎没有磁盘I/O操作。使用性能相关如何使用StarTeam进行配置管理也会对某些特定操作的性能产生很大影响，下面总结了会对内存占用、数据库性能、客户端响应速度产生较大影响的因素：同时连接的客户端数：每个并发连接都会在StarTeamServer进程中占用少量的资源，每个活动的客户端请求也会分配到一个工作线程和一个可用的数据库连接；打开的视图个数：使用StarTeam客户端打开的每个视图都需要缓存一些与视图相关的信息。在一个客户端session内，暂时回滚到某个以前的视图也需要缓存一些信息；每个视图中item的个数：一个活动视图需要的缓存大小与视图中显示的项的个数成正比；分支视图的个数及层次：分支视图的数量和层次越多，针对特定事务启用的数据库进程也越多；可派生视图的创建：创建可派生所需要的时间与父视图中显示的工作产品的数量成正比。、数据库容量规划相关StarTeam支持Oracle、MicrosoftSQLServer(以及MSDE)和IBMDB2数据库。当存储库支持的是小型团队（50－100人），而工作产品数量不超过中型（数千个工作产品）时，可以使用MSDE作为数据库存储库。当存储库需要支持大型团队（几千或上百个用户），或者工作产品数量巨大（上万或者更多）时，需要选择一种商业数据库。StarTeam存储库的增长主要取决于一些三种类型的信息：Object表：StarTeam会为每一类进行版本控制的对象（文件、文件夹、CR、Task和topic）建一个相应的表存储工作产品类型相关的数据。会给每个对象的初始版本创建一条记录，当对象被修改时，也会给后续的修订创建相应的记录。每个对象的记录将占用100－200字节，此外，每个工作产品表可以有2－4个索引，每个索引可以使每条记录的数据量增加50％。可以假设每个对象的修订占用400个字节，并以此进行粗略的估计。视图成员（Item）表：当向StarTeam视图中增加需要版本控制的对象时，会创建一个视图成员，或称为项。通过item将对象和视图关联起来了，并使用item来存储对象在视图中的特定属性。所有的item数据都存储在一张有索引的单独的表中，同时，表和索引记录中，每个item都需要300字节的空间。注意，当对象在多个视图中共享时（例如，从父视图派生一个子视图），每个视图中item的个数都在增加。例如，当1000个文件在三个不同的视图中都出现时，会创建3000个项（大概需要900K）。Log表：在存储库中，StarTeam维护了两种不同类型的日志表，记录不同的事务。在Audit表中，记录StarTeam中所有对象的版本变化，类似流水账。在SecurityLog表中记录安全相关的事件，包括工作产品相关的变更（例如，权限调整），session相关的事件（例如，登录失败）。这两类表中记录都相对较小，不过表中的记录都会持续增长最终达到限制的大小。表大小的增长取决于这些事件发生的频率。StarTeam配置库的大小和增长率可以通过上述三种信息类型的数据量及变化情况进行估计。、Vault容量规划相关前面提到过,每个StarTeam配置库都包含一个Vault，而Vault又是由archive、cache、attachment三部分组成,这三个部分还可以部署在不同的地方。对于新的StarTeam配置库，这三个文件夹都是空的，只有当文件对象被添加到配置库中时，才会向archive、cache、attachment文件夹中新增vault文件。对archive文件夹大小的增长产生影响的因素有：当向配置库中添加需要版本控制的文件时，会相应的新增一个archive文件；archive文件包含版本控制文件的初始化内容及一小段的信息。默认情况下，这些信息是经过压缩的，所以初始archive文件会比原始文件要小。压缩比根据数据类型不同而不同，例如对于已经压缩过的文件格式（如，.zip和.gif）实际上不会再压缩了，而对于文本文件，因为有许多空白空间和重复的内容，压缩比将接近5：1。下表给出了默认压缩情况下，典型的原始文件与archive文件压缩情况：文件类型原始大小初始archive文件大小压缩率Text(HTML)29KB10KB.36Binary(PDF)248KB186KB.75Source(C++)33KB8KB.24可以针对某些文件选择不同的压缩类型。默认的压缩是在效率和压缩大小之间的平衡点。对于不同需要可以选择“压缩速度最快”、“压缩比最大”或者“不压缩”；当版本控制文件的新修订被签入时，修订信息被附加到相应的archive文件上。如果文件是文本类型的，修订信息默认按增量存储并与变更的大小成正比。对于二进制文件，整个新的修订都默认被附加到archive文件上。这两种情况对应的压缩比都与初始文件的压缩比相同。可以使用这种方法估算某个文件在archive中占用空间的大小；注意：因为Archive文件的大小限制在4G以内，所以对于较大的文件，archive的压缩技术将影响可以存储的文件的最大修订；对cache文件夹大小的增长产生影响的因素有：当配置库中某个文件的新版本被提交到配置库时，会在cache文件夹中保存一个副本。因为，文件被提交到配置库以后会经常有签出操作，所以这个副本可以提高后续签出操作的效率；如果需要签出最新的或是历史的修订版本，而这个文件版本在cache中无法找到时，会到archive文件夹中找到相应的修订版本并在cache文件夹中添加一个副本；Cache文件夹中会维护一个包含所有文件名的近期使用文件列表。当一个新文件添加到cache中，或者cache中的某个文件被使用时，该文件的文件名会出现在近期使用列表的第一个；Cache文件夹的总文件大小由StarTeamServer的后端线程监控，一旦超出最大容量限制，会从近期使用文件列表的最后一部分找到近期最少使用的文件并删除该文件；Cache文件夹允许的最大容量为4G（对于StarTeam5.4版本）；出于性能方面的考虑，Cache文件夹必须能够保存所有版本控制下文件的最新修订；Attachment文件夹中存储CR或者其他对象的附件，这些文件不需要进行版本控制，它们存储时并没有进行压缩和增量存储。相对于Archive文件夹，此文件夹的总大小和增长率都较低。、服务器各组件硬件配置建议下面分别给出StarTeamServer进程及DatabaseServer进程单独部署时，所要求的最低的和推荐的硬件配置。StarTeam和MSDE部署在一台机器上当使用MSDE作为数据库时，数据库和StarTeam相关的服务进程都在同一台机器上，下面给出了这台机器的硬件配置要求：注册用户数最低配置推荐配置小于50Pentium®4,1.3GHz,1.5GBofRAMDualPentium4,1.3GHz+,2GBofRAM50－100DualPentiumXeon™,2.26GHz+,2.5GBofRAMDualPentiumXeon™,2.26GHz+,2.5GBofRAM注意：当注册用户数超过100时，不推荐使用MSDE。StarTeamServer进程部署在单独的机器上当StarTeamServer进程单独部署时，参考以下配置建议：注册用户数最低配置推荐配置小于50Pentium4,1.3GHz,512MBofRAMDualPentium4,1.3GHz+,1GBofRAM50－100DualPentium4,1.3GHz,1GBofRAMDualPentium4,1.3GHz+,2GBofRAM100－200DualPentiumXeon4,2.26GHzand1.5GBofRAM.Dual/QuadPentiumXeon4,2.26GHzand2.5GBofRAM.大于200AnyhighperformanceEnterpriseServerwithRAIDsystem(recommended),quadprocessorswith2.26GHz+,4.0GBofRAMAnyhighperformanceEnterpriseServerwithRAIDsystem(recommended),quadprocessorswith2.26GHz+,4.0GBofRAMDatabaseServer硬件推荐当DatabaseServer进程单独部署时，参考以下配置建议：注册用户数硬件配置数据库小于50Pentium4,1.3GHz,1GBofRAM最低配置：MSDE2000SP2建议配置：SQLServer,Oracle,DB250－100DualPentium4,1.3GHz,2GBofRAM最低配置：MSDE2000SP2建议配置：SQLServer,Oracle,DB2100－200Dual/QuadPentiumXeon4,2.26GHzand2-3GBofRAM建议配置：SQLServer,Oracle,DB2大于200AnyhighperformanceEnterpriseServerwithRAIDsystem(recommended),quadprocessorswith2.26GHz+,4.0GBofRAM建议配置：SQLServer,Oracle,DB2精品文档精心整理精品文档可编辑的精品文档基线建立控制报告基本信息项目编号项目名称申请日期申请人员配置管理员基线建立申请及审批基线名称设计基线基线版本1.0基线所包含的主要配置项项目立项报告项目管理计划风险/重大问题跟踪表项目路线图需求说明书需求规格说明书品质保证计划品质保证检查记录配置管理计划需求基线建立控制报告设计说明书数据库设计说明书建立原因及可能的影响需求阶段结束。无影响。建立申请人签字基线建立申请审批CCB审批意见同意CCB负责人签字：日期：基线建立报告本基线包含的主要配置项名称当前版本存放路径提交人项目立项报告\01项目管理\01项目启动项目管理计划1.1\01项目管理\02项目计划风险/重大问题跟踪表\01项目管理\05管理跟踪项目路线图\01项目管理\03品质保证需求说明书1.1\02需求\02需求确认需求规格说明书1.0\02需求\02需求确认品质保证计划1.1\01项目管理\03品质保证\01管理策略品质保证检查记录\01项目管理\03品质保证\02品质保证检查记录配置管理计划1.0\01项目管理\04配置管理\01管理策略需求基线建立控制报告1.0\01项目管理\04配置管理\02基线建立设计说明书1.0\03设计\02设计确认数据库设计说明书1.0\03设计\02设计确认结束申请CCB签字同意CCB负责人签字：日期：精品文档精心整理精品文档可编辑的精品文档文件编码文件密级最新发布日期当前版本配置管理工作指南变更履历版本日期变更位置变更理由/变更内容变更人备注1.0新建1.12.1.1、变更履历根据研发项目管理流程问题巡检检查出的问题进行更新：1、更新2.1.1基线配置项参考列表2、增加变更履历2.0全文根据新版《配置管理规范》和目前实际工作进行调整，调整整体框架、将冗余的内容进行删减、优化。目录1 概述 41.1 角色与职责 41.2 工作目标 51.3 流程概述 52 术语定义 63 阅读对象 64 制定配置管理计划 64.1 配置管理软硬件资源确定 74.1.1 明确软硬件资源 74.1.2 个人工作空间配置参数要求 74.2 配置项管理 74.2.1 配置项识别 74.2.2 配置项标识 104.2.3 配置项入库管理 104.3 配置库目录结构规划 104.4 制定基线计划 124.4.1 基线标识 124.4.2 制定基线计划 124.5 明确权限管理 134.5.1 用户管理 134.5.2 制定访问控制策略 134.6 明确分支版本策略 154.6.1 分支合并类型 154.6.2 明确分支版本策略 164.6.3 基于SVN的分支建立及合并方法 175 个人工作空间管理 195.1 建立个人工作空间 195.2 个人工作空间要求 205.3 检查个人工作空间 206 基线管理 206.1 基线建立要求 206.2 基线变更管理 217 分支合并管理 217.1 分支合并流程 217.2 分支合并方案制定 228 集成构建 238.1 代码集成 238.1.1 代码更新说明范围界定 238.1.2 代码更新说明填写 238.1.3 代码更新说明发布 248.2 准备构建环境 248.3 构建测试版本 259 发布管理 259.1 正式版本发布 259.2 测试版本发布 269.3 临时版本发布 269.4 产品版本号编码 2610 备份/还原管理 2711 记录配置管理活动 2712 参考及附录 27

概述本文的目的是描述配置管理的所有活动应如何开展，为配置管理活动提供指导。角色与职责对于任何一个管理流程来说，保证该流程正常运转的前提条件就是要有明确的角色、职责和权限的定义，软件配置管理过程中主要涉及下列的角色和分工：No.角色职责1变更控制委员会ChangeControlBoard，CCB负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。具体职责如下：评审、批准项目计划等，评估、审批配置项的变更请求等。批准配置管理策略，如访问控制、基线计划、集成构建、分支合并、版本发布等。根据配置管理报告决定相应的对策。2项目经理ProjectManager，PM项目经理是整个软件研发活动的负责人，他根据软件配置控制委员会的建议批准配置管理的各项活动并控制它们的进程。具体职责如下：制定和修改项目的组织结构和配置管理策略。批准、发布配置管理计划。决定项目各类基线和研发里程碑。审阅配置管理报告。3配置管理员（ConfigurationManagementOfficer，CMO）根据《配置管理计划》执行各项管理任务，具体职责如下：配置管理工具的日常管理与维护。制定《配置管理计划》。配置项日常管理与维护。执行版本控制和变更控制方案。完成配置审计。对项目组成员进行配置管理规范、工具等培训。跟踪软件研发过程、识别存在的问题并拟就解决方案。4系统集成员SystemIntegrationOfficer，SIO系统集成员负责生成和管理项目的内部和外部发布版本，具体职责如下：建立、维护构建环境，包括明确构建服务器、构建工具选型及配置、明确发布服务器、发布位置及发布方法等。完成构建脚本或构建配置。完成代码集成、版本构建。发布构建版本。5开发人员（Developer，DEV）根据确定的《配置管理计划》和相关规定，按照配置管理工具的使用模型来完成开发任务。工作目标通过实施配置管理来提高软件开发管理的水平，增强企业自身的竞争力，应对市场的压力，解决以下软件开发中的常见问题：开发人员未经授权修改代码或文档。人员流动造成企业的软件核心技术泄密。无法重现历史版本，使维护工作十分困难。“合版本”时，开发冻结，造成进度延误。软件系统复杂，编译速度慢，造成进度延误。因一些特性无法按期完成而影响整个项目的进度或导致整个项目失败。已修复的Bug在新版本中出现。开发团队难于协同，可能会造成重复工作，并导致系统集成困难。最终实现以下目标：控制工作产品的识别、提交、入库和存储，确保项目过程中所有工作产品纳入统一数据库管理。建立基线概念，使版本与一系列内在一致的工作产品相关联，这里的工作产品包括代码、文档、测试数据、构建的二进制文件，能够保证配置库中各历史版本的完整复原。为开发团队建立一致的开发配置环境，开发配置环境包括开发工具、工作空间、开发过程中引用的代码、文档、二进制文件。建立组织配置库的安全管理策略，确保配置库的建立、迁移、存储、复制、发布、访问、删除都处于受控的信任环境下，配置库的访问应能保证合适人员能够访问他应该访问数据、文档、代码，而且也只能访问他责任范围之内数据、文档和代码。流程概述项目经理制定《项目管理计划》后，配置管理员应与项目经理一起进行配置管理活动的策划，形成《配置管理计划》，作为配置管理活动的基础。它的主要流程如下：项目经理和配置管理员共同确定本项目配置管理的软硬件资源。依据《项目管理计划》，配置管理员与项目经理共同识别主要配置项、规划配置库目录结构、制定权限分配策略、确定基线计划等。配置管理员与项目经理共同确定项目的变更策略、分支合并策略、集成构建策略以及版本发布策略等。配置管理员完成《配置管理计划》。《配置管理计划》评审活动由配置管理员发起，评审组由CCB成员组成。CCB对已制定的《配置管理计划》进行评审，直至CCB评审通过。配置管理员将审批通过的《配置管理计划》纳入配置库进行管理，并发布给项目组相关人员。以上各活动具体要求，可参考《配置管理规范》。

No.术语定义1配置管理（CM）配置管理是对项目生命周期过程中各阶段产品和最终产品演化和变更的管理，是质量管理的重要组成部分。配置管理通过一系列技术、方法和手段实现：指导和监督对配置项的物理与功能特性的标识和归档工作。控制上述特性的变更，记录并报告变更的处理和实现状态，并验证与需求的一致性。2变更控制委员会（CCB）CCB是一个虚拟小组，由项目监理小组、项目经理、资深项目成员、配置管理员、品质保证工程师等组成，项目经理为CCB召集人；CCB对配置管理各项活动拥有决策权（例如评审计划、评审变更请求等），负责评估和审批配置项的变更、确保所有的变更都是经过审核的。3配置项（ConfigurationItem,CI）配置项是指纳入配置管理范畴的工作成果的最小集合。例如一个文档（如需求文档、设计文档、测试用例、用户文档等属于产品组成部分的工作成果以及项目管理、组织支撑过程域产生的文档）或一组构成独立功能单元的源代码文件都可以定义为一个配置项。4基线（Baseline）基线由一组稳定的特定版本的配置项组成，是进一步开发的基础。基线中的配置项是被“冻结”的，不能被随意修改。基线通常在开发过程中的里程碑（Milestone）处建立，一般包括需求基线、设计基线、开发基线、发版基线、结项基线等。5配置管理员（CMO）每个项目应配备一个配置管理员（可专职或由项目组某个成员兼职），为该项目制定《配置管理计划》、创建和维护配置库、适时出具配置管理各种报告如基线建立控制报告、配置项变更控制报告、版本发布通知等。术语定义阅读对象配置管理员、产品/项目经理制定配置管理计划《配置管理计划》的制定过程由明确配置管理软硬件环境、识别配置项、规划配置库目录结构、制定权限分配策略、制定基线计划、明确分支版本策略、明确集成构建策略、明确版本发布策略等一系列活动组成。每个活动的最终成果体现在《配置管理计划》中，相关流程说明可查看《配置管理规范》第5章节内容。配置管理软硬件资源确定配置管理员与项目经理沟通确定配置管理环境，包括软硬件资源、部署结构、服务器端配置参数要求、个人工作空间配置参数要求等。确定使用何种配置管理工具、其部署情况、配置管理服务器的参数要求等。公司明确规定新立项目自2010年开始，全部使用jqcm配置管理服务器以及SVN配置管理工具。有关服务器和工具的详细信息已列示在《配置管理计划（模板）》中。明确软硬件资源硬件资源明确配置管理服务器以及配置管理工具：配置管理服务器的软硬件配置、是集中式管理还是分布式部署（一般情况下，公司配置管理服务器采用集中管理的方式）；配置管理工具客户端软件或插件的版本。预估所需的磁盘容量：为保证选择的机器硬件可以在今后一段时间内（如，五年内）满足可能的需求，需要预先估算配置管理服务器的使用情况、了解配置管理工具对硬件的要求。软件资源确定CCB成员名单，根据项目不同规模和重要程度，CCB成员建议可以包括分管副总、研发项目总监、部门经理、项目经理以及其他受变更影响的人员代表（必要时可包括测试人员等）。确定本产品/项目研发人员需遵循的编码规范、界面规范或其他开发规范。个人工作空间配置参数要求项目组在编码前需要使团队工作在统一的工作平台上。配置管理员需要与项目经理沟通确定使用的开发/测试平台、开发/测试机的软硬件环境等，并最终记录在《配置管理计划》中。项目组成员应按照《配置管理计划》中约定的个人工作空间配置参数要求准备开发、测试或文档编写等环境。配置项管理配置项识别在制定项目管理计划时，项目经理需要首先识别配置项，并指定基线配置项、非基线配置项。在执行项目配置管理时，需要重点控制基线配置项，在识别项目配置项时，配置管理员需完成以下工作：配置管理员参照公司《配置项参考列表&配置库参考目录.xls》制定本项目配置项列表。配置管理员与项目经理和项目主要成员确认项目配置项列表。配置管理员确认工作成果的内容，确定是否可以与现有配置项合并或者作为新的配置项。配置管理员与项目经理确认，识别新的配置项。配置管理员识别出新配置项为基线类配置项或非基线类配置项。基线配置项参考列表项目经理制定项目里程碑计划时，需要明确各里程碑产生的配置项。配置管理员根据里程碑计划制定基线计划。基线配置项往往需要严格控制，并会对项目基线建立产生影响。基线配置项确定标准如下：重要的提交物。配置项易发生变化，需要进行版本控制。属于管理控制重点的配置项，如源代码。下表给出了基线配置项参考列表，各项目可以根据实际情况确定相应的基线配置项。

表1基线配置项参考列表类型配置项配置项分类备注项目管理项目管理计划基线类配置项项目进度计划基线类配置项项目周报基线类配置项项目里程碑报告基线类配置项评审报告/会议纪要基线类配置项风险/重大问题跟踪表基线类配置项配置管理计划基线类配置项基线建立控制报告基线类配置项基线建立前检查Checklist基线类配置项品质保证计划基线类配置项项目路线图基线类配置项项目总结报告基线类配置项遗留问题跟踪表基线类配置项提交工作产品清单基线类配置项需求定义概要技术方案说明书基线类配置项需求说明书基线类配置项需求规格说明书基线类配置项设计开发技术研究报告基线类配置项设计说明书基线类配置项数据库设计说明书基线类配置项系统稳定测试计划基线类配置项测试用例基线类配置项测试总结基线类配置项功能/性能测试报告基线类配置项发版说明基线类配置项产品化包装用户手册基线类配置项培训资料基线类配置项系统安装配置说明书基线类配置项产品介绍PPT基线类配置项产品解决方案基线类配置项产品实施指南基线类配置项产品报价策略基线类配置项技术白皮书基线类配置项非基线配置项参考列表项目非基线配置项区别于基线配置项，是指没有纳入基线计划的配置项。非基线配置项一般不影响项目进展，不需要在基线建立时进行严格控制。下表给出了非基线配置项参考列表，各项目可以根据项目实际情况确定相应的非基线配置项。

表2非基线配置项参考列表类型配置项配置项分类备注项目管理项目立项报告、项目启动会PPT等非基线类配置项配置管理相关文档非基线类配置项品质保证相关文档非基线类配置项项目汇报相关文档非基线类配置项各种管理跟踪表非基线类配置项会议评审相关文档非基线类配置项培训相关文档非基线类配置项项目结项总结PPT等非基线类配置项电子邮件非基线类配置项…非基线类配置项需求定义调研准备非基线类配置项调研资料非基线类配置项…非基线类配置项设计开发其他设计类参考资料、文档非基线类配置项源代码源代码、单元测试源代码非基线类配置项可执行文件非基线类配置项系统稳定缺陷跟踪相关文档非基线类配置项维护记录相关文档非基线类配置项产品化包装用户培训资料、帮助等非基线类配置项系统维护系统维护相关文档非基线类配置项…………非基线类配置项在项目进展过程中，配置管理员需定期跟踪并维护项目配置项列表（体现在《配置管理计划》中），需注意以下各项工作：配置管理员每周阅读项目周报、每月阅读项目月报，关注周报、月报中列出的项目工作成果。配置管理员对照《配置管理计划》的配置项计划，识别出未纳入计划的配置项清单。配置管理员就新配置项清单与项目经理和项目主要成员确认。将新识别的配置项清单更新到《配置管理计划》中（将新的基线配置项列入基线配置项列表，将新的非基线配置项列入非基线配置项列表）。将新经过评审的基线配置项和正确的非基线配置项纳入配置库。基线配置项入库后如需修改请遵循变更流程。配置项标识标识的本质就是区分，在众多的配置项中合理、科学的命名是最好的区分方法。所有配置项都应按照相关规定统一编号，按照相应的模板生成。配置项标识需要遵循以下原则：唯一性可追溯性与同类配置项不同的信息，应纳入标识：这是为了便于区分、查找同类配置项的标识方法统一容易记忆配置项标识需要遵循以下要求：所有纳入管理的配置项必须按照公司文档编码规范进行命名（不包含配置库草稿目录下的草稿文件），配置项的命名要遵守“项目编号+项目名称+文档产品+可选字段（主题/版本/人名/日期）”的命名原则，同时命名要求需体现在《配置管理计划》中，详细内容请参见《文件编码及命名规范》。基线配置项必须符合文档规范，需使用公司最新发布的文档模板（若客户方有特殊要求，需提前说明），各类最新项目文档模板可直接进入公司portal主页-规章制度下获取。新建或修改基线配置项的文档内容时，必须同时填写相应的变更履历。配置项入库管理配置项的存放目录应参考组织级配置库目录，由配置管理员在配置库中建立。配置项必须按照《配置管理计划》中配置库目录结构划分的要求纳入到正确的目录中。配置项需及时、正确入库，配置管理员或项目经理/工作产品负责人根据项目周报中的工作成果每周检查、并督促入库。配置项的首次入库时间不以基线建立时间为准，应以评审、定稿时间为准，最多不得超过两周时间、并且必须在基线建立前；对配置项的修改或变更在评审、定稿后同样应及时入库。配置项的正式发布必须在配置库的正式目录中，不得存放于工作草稿等目录中。产品/项目进行过程中产生的各种需求、设计、测试、实施、评审、培训等以及项目管理的最终文档、中间文档以及附带的图稿原件如时序图等，临时产生的各种用于交流、讨论、备忘的记录、材料等，均应该完整、及时纳入配置库，由项目经理负责检查落实，配置管理员定期督促。对于主要配置项，如需求规格说明书、项目管理计划等的变更，需要走“申请-CCB审批-CM检出-变更-CCB审批-检入”的变更流程。配置库目录结构规划公司所有项目配置库目录可参照组织级《配置项参考列表&配置库参考目录》创建。整个配置库目录需要按《配置管理计划》中的配置库目录结构要求创建。

表3配置项参考列表&配置库参考目录一级目录二级目录三级目录内容说明备注项目管理项目立项项目立项申请、项目启动会PPT（可选）、项目基本信息表等项目计划项目管理计划、项目进度计划项目汇报项目周报项目周报其他报告项目里程碑报告、阶段性汇报PPT（可选）等管理跟踪风险/重大问题跟踪表、项目备忘大事记（可选）配置管理管理策略配置管理计划基线建立基线建立控制报告、基线建立前检查Checklist变更管理配置项变更控制报告（可选）、变更控制重点监控配置项清单（可选）、重点控制项变更检查表、产品发布更新说明（产品型项目）品质保证管理策略品质保证计划检查记录项目路线图、品质保证检查记录（工作流程审计、工作产品检查、工程规范检查）会议评审会议纪要、评审报告、会议签到表（可选）、评审数据汇总表（可选）等可按事件等建立子目录培训培训通知（可选）、培训材料（可选）、培训签到表（可选）、培训评估报告（可选）可按事件等建立子目录电子邮件与客户往来沟通确认的工作邮件存档、项目组内部沟通确认的工作邮件存档可按主题等建议子目录项目结项项目总结报告、项目结项总结会PPT（可选）、提交工作产品清单、遗留问题跟踪表其它需求定义需求调研调研计划、调研提纲、调研报告&访谈记录需求草稿从客户或其他途径获得的资料、需求草稿需求确认产品可研论证报告（产品型）、产品/项目愿景说明书、项目范围说明书（普通）、需求说明书、需求规格说明书、需求跟踪矩阵（可选）设计开发设计草稿设计草稿文档设计确认概要技术方案说明书、总体/模块设计说明书、数据库设计说明书、模块依赖关系表、技术研究报告（可选）系统稳定管理策略测试计划测试用例测试用例、测试点（可选）、性能测试方案（可选）测试报告阶段测试总结（可选）、系统测试报告、功能/性能测试报告（可选）、用户验收测试报告（可选）上线及试运行实施日志（普通）、实施配置报告（普通）、问题跟踪一览表、项目分工界面（可选）、项目验收备忘录（普通）、用户验收证书（普通）可选版本发布发版申请、发版计划、正式版产品发布基线清单、产品发布更新说明产品化包装用户文档用户手册、帮助、系统安装配置说明书、用户培训资料等产品包装产品技术白皮书、产品解决方案、产品宣传彩页、产品介绍PPT、产品实施方案、产品咨询方案、产品报价策略系统维护年度1维护事件1可选年度2源代码开发源代码制定基线计划基线标识计划性基线：“项目编号-阶段标识-YYYYMMDD”。事件性基线：“项目编号-阶段标识-事件英文缩写-YYYYMMDD”。制定基线计划基线分为计划性基线和事件性基线，计划性基线在《配置管理计划》中体现，事件性基线由相关人员提出申请建立，不在《配置管理计划》中体现。

表4基线参考列表基线名称/标识符包含的主要配置项建立时间产品定义基线：项目编号-REQBaseline-YYYYMMDD需求说明书需求规格说明书项目管理计划品质保证计划配置管理计划测试计划风险/重大问题跟踪表各种报告和跟踪表产品设计与开发基线：项目编号-DES+CODEBaseline-YYYYMMDD概要技术方案说明书总体/模块设计说明书数据库设计说明书测试用例源代码产品发版/稳定基线：项目编号-RELEBaseline-YYYYMMDD功能/性能测试报告用户手册培训资料技术白皮书发布版本项目结项基线：项目编号-ENDBaseline-YYYYMMDD项目总结报告提交工作产品清单遗留问题跟踪表注：基线计划时间出现2周以上偏差或主要配置项变更时，需要走变更流程。明确权限管理用户管理用户角色组主要有：配置管理员、CCB、项目经理、需求人员、设计人员、开发人员、测试人员、实施人员、品质保证员等。各用户角色定义详见《配置管理规范》9.1章节,对项目配置库中用户角色的管理，配置管理员需注意以下几点：项目配置库用户需要根据项目情况相应调整。一般情况下，项目配置库用户如需调整增加或删除，由项目经理提交邮件申请，配置管理员收到邮件申请后，执行相应操作。特殊情况下，可由项目组成员提交邮件申请，抄送项目经理及相关人员。配置管理员在收到邮件申请后，执行相应操作，并将用户分配到不同组里。配置管理员增加或删除用户后，需要邮件通知项目经理及相关人员。邮件通知中需要附加配置库连接地址及简要操作说明。制定访问控制策略在建立配置库以前，项目经理需要给配置管理员提供明确的项目组各成员角色的访问控制策略，配置管理员结合配置管理工具，衡量访问控制策略的合理性，与项目经理确认后制定访问控制策略，并记录到《配置管理计划》中。配置库资源与操作定义不同角色用户对配置库操作主要有：项目配置库创建、维护、删除。项目成员及组的设置、维护。基线建立、维护。分支/合并。对文档、目录的读写访问。对源代码文件、源代码目录的读写访问等。由于不同配置管理工具对配置库操作的控制粒度不同，在具体设置配置库操作权限时，需要结合配置管理工具的特性进行设置。表5配置库操作列表序号资源SVN操作定义1配置库创建文件夹：CreateFolder删除文件夹：Delete分支/建基线(打标签)：Branch/tag合并：Merge访问控制：设置用户组的权限2项目文件夹读(Read)：Checkout、Export、update写(Write)：Add、commit、Get/ReleaseLock、Rename、delete、Copyto3项目文件读(Read)：Checkout、Export、update写(Write)：Add、commit、Get/ReleaseLock、Rename、delete、Copyto4代码目录读(Read)：Checkout、Export、update写(Write)：Add、commit、Get/ReleaseLock、Rename、delete、Copyto角色划分策略配置库角色主要有：配置管理员、项目经理、开发人员、测试人员、实施人员，不同角色的职责不同。配置库授权控制参考列表如下：表6角色划分参考列表序号资源配置库操作配置管理员项目经理需求/设计/开发人员测试人员CCB/实施/品质保证人员1配置库配置库创建、维护、删除完全无无无无用户及角色组的设置、维护、授权控制完全无无无无基线建立完全无无无无分支/合并完全无无无无2文件/文件夹读写访问完全读写读写读写只读3源代码读写访问完全读写读写无无4产品库读写访问完全只读只读读写只读配置库操作权限参考

表7配置库操作权限参考列表编号一级目录权限说明1项目管理项目经理、配置管理员可写，CCB、测试人员、QA人员可读2需求定义项目经理、配置管理员、开发人员可写，CCB、测试人员、QA人员可读3设计开发项目经理、配置管理员、开发人员可写，CCB、测试人员、QA人员可读4系统稳定项目经理、配置管理员、测试人员可写，CCB、开发人员、QA人员可读5上线及试运行项目经理、配置管理员可写，CCB、开发人员、测试人员、QA人员可读6产品化包装项目经理、配置管理员可写，CCB、开发人员、测试人员、QA人员可读7系统维护项目经理、配置管理员可写，CCB、开发人员、测试人员、QA人员可读8源代码项目经理、配置管理员、开发人员可写，CCB可读，测试人员、QA人员无权限明确分支版本策略分支合并类型在软件开发实践中，常常出现一些令人沮丧的事，如软件紧急更改提交集成失败、发布错误版本、修复过的缺陷又莫名其妙地出现等等。主要的原因在于在实际开发中没有应用软件配置管理或应用软件配置管理不当，选择并应用正确的分支模型，对避免开发过程的混乱尤其重要。常见的分支合并类型有以下几种：分支合并到分支；分支合并到主干；主干合并到分支。项目组根据项目情况不同，需事先约定所选择的合并类型，以便为后期可能的分支合并做好准备，配置管理员将所选择的类型记录到《配置管理计划》中。分支合并前应临时去除相关分支所有人员的写权限，只保留被合并分支上合并人员的读权限。应当尽量避免一个分支合并多次。当一个分支完成特定任务后，应及时合并。合并完成后分支应设置为只读，不再允许对该分支进行修改。明确分支版本策略选择正确的分支策略使版本正确发布、重构以前的版本或者重新回到以前的版本等工作更加容易。采用分支模型使软件开发过程更加便捷、软件开发更加高效、软件质量得到提高，并且可以减少软件开发中的错误和提高软件开发团队的整体效率。选择适当的分支模型，应从以下几个方面考虑：支持连续不间断的集成，从而保持新开发过程的稳定的基准；提交应急版本（只包括所有必要的修复）进行测试和交付用户；包含有所有必要的修复而无其它更改的测试版本发布；使应急发布对新开发过程的影响最小化；根据项目需要，回退到以前的产品状态；支持多个共存版本，如不同平台或不同用户的备选版本。关于代码管理的分支和发布策略，主要有两种模式：新功能开发在分支上进行，主干用于稳定版的发布。新功能开发在主干上进行，分支用于稳定版的发布。主干稳定当新功能开发在分支上进行、开发结束、功能测试通过时，将分支合并到主干修订集成测试、系统测试所发现的BUG，在主干上进行发版；同时将分支设置为只读。主干稳定策略与分支稳定策略刚好相反，主干上永远是稳定版本，可以随时发布。缺陷修改和新功能的开发都在分支上进行，而且每个缺陷修改和新功能都有不同的开发分支，是完全分离的，在分支上测试通过后才合并到主干，在主干上的每一次发布都需要用标签标识。优点：开发周期较灵活，各功能模块自主定义开发周期，每个分支的生命周期比较短，唯一长期存在的就是主干，这样每次合并的风险比较小。每次发布的内容调整起来比较容易。如果某个新功能或缺陷修改在发布之前无法完成，就不会合并到主干，也不会影响其他变更的发布。缺点：如果某个开发分支因为功能比较复杂，或其他原因长期没有合并到主干，则最后合并的时候很可能会出现冲突。为避免合并时产生冲突需要注意以下问题：如果有的分支确实因为特殊的需要必须长期存在，那就必须定期把主干的更新往这个分支上合并。如果发布周期很长，各个发布分支之间还要定期的从前向后合并。测试在发布分支上进行，而发布在主干上进行，这就引入了合并出错的风险，而主干上的程序是没有经过测试的。分支稳定当新功能开发在主干上进行、临近发布阶段时，从主干建立分支，在分支上修订集成测试、系统测试所发现的BUG，在分支上进行发版；主干继续进行新功能开发。版本发布完成后，将分支合并到主干，分支设置为只读。采用分支稳定策略情况下，主分支中永远是最新的功能，当新功能开发到达某个里程碑后发布，从主干分支用于该版本的缺陷修改及现有功能的完善。当稳定分支上的修改积累到一定程度就会进行一次发布。优点：这种发布方法非常适用于产品线的发布管理，以前的版本仍需要继续维护，而新功能也不断地在增加。对于已经发布的产品，只有维护的补丁发布。而新发布的产品不仅包括了所有的bug修改，还包括了新功能。缺点：只能增加下一个发布里面计划集成进去的新特性，同时必须对主干上新功能的增加进行控制，否则新版本的发布将出现严重延期。如果主干上的某个新功能，测试不通过，达不到里程碑的要求，新版本的发布也会出现延期。缺陷修改必须在各个分支之间合并，各个长期存在的分支之间必须要周期性的进行合并，否则很容易引发合并冲突。因此，采用这种分支策略可能碰到的最大问题就是某个分支上的bug修改内容往其它分支merge的时候出现的冲突。而且一旦发现一个bug，调查这个bug影响哪些分支的工作会随着维护的发布分支的数量而增加。基于SVN的分支建立及合并方法表8SVN分支建立及合并方法参考列表操作SVN分支/合并操作说明新建分支1Branch/tag（分支标记）方法一：当新建分支时，在工作副本右键点击要开分支的文件目录，选择“Branch/tag”功能创建分支。2Copyto（复制到）方法二：使用TSVN客户端浏览器，选择”Copyto”功能将需要建立分支的文件夹”复制”到branches目录下。合并分支Merge（合并）选择所需要使用的合并类型进行合并。(合并步骤参考本指南4.6.3.2章节)。分支建立步骤由于SVN提供可以创建从主干向分支、分支向主干、分支向分支三种类型的分支，首选需明确开分支的起始位置及结束位置。新建分支的操作方法有两种，如上表所属（表8），使用第一种方法需在工作副本中进行，第二种方法通过SVN浏览器完成。选择分支文件所存放的目录路径，一般情况下，分支文件存放在branches目录下，以上信息明确后即可开始创建分支。分支创建完成后，开发人员再次确定分支目录结构是否有需调整。分支创建完成后，配置管理员需明确配置库分支目录文