【转帖】配置管理计划(CM Plan)
作者:scmroad
出自：配置管理之路 http://bbs.scmroad.com/
版权所有，转载请注明原作者和出处，谢谢合作。
目的：这篇文章主要想和大家交流下，我们在写配置管理计划的时候都应该写些什么。写配置管理计划对于一个CM来说是一个必修课，也是一个必须修好的课程。但是很多新手都不知道如何下手。公司有模版的还好点，如果要是让一个新人从头开始为一个新项目写一个配置管理计划，那就要抓瞎了，这里我只把我想到的一些列了出来，可能有些地方不对，或者需要补充，还希望大家都能指出来。大家一起交流，共同进步，谢谢。
＃扉页
- 文档名称
- 文档的版本信息
（哪年哪月哪日哪个人修改了哪些内容，这里的哪人一般都是负责这个项目的CM,例如，v0.1, 2009.08.05, scmroad， xxx项目配置管理计划初稿）
- 审查者(一般，配置管理计划写出来后，要让相关的人员进行审查。至于审查人员则根据公司有差异）
＃内容的索引页
＃介绍部分
项目介绍（比如项目的产品名，项目名...)
项目组成员联系人(CM，PM,QM,TestManager联系人，不一定都写上，直接负责人都写上就可以了）
缩写词（告诉人家啥叫CM）
＃相关文档
这部分内容可能不同公司有不同的标准，有的公司CM plan写的很大，很全，那么这部分引用的文档就很少；而有的公司把在CM plan中比较独立的内容，单独抽出来形成了一个文档，那么这里就要作为相关文档列出来。通常应该包括以下文档
- 项目计划（project plan),
- 代码书写规范，
- 命名规范，
- 配置管理工具的简单使用文档
（不要那种什么Clearcase，Perforce， svn手册之类的，CM应该自己整理一份开发人员最经常使用的操作写出来，后边最好还要加个FAQ部分）
＃版本管理库管理
项目所在的版本库位置在哪里，地址是什么
项目组成员创建版本库访问帐号的流程，创建帐号是否需要CM Manager审批？等等
项目组成员版本库权限分配情况
标签的创建和使用管理
＃分支管理策略
介绍在这个项目中我们要利用什么样的分支管理模型。
这部分可以单独形成文档，然后作为相关文档在配置管理计划里引用。
＃构建服务器的搭建和管理
构建服务器的硬件详细说明
构建服务器的软件安装详细说明
＃项目构建
版本号管理
如何构建项目（可以由开发人员提供）
是否采用持续集成
构建脚本说明书
构建脚本（构建脚本要放到版本管理库中，可以给出构建脚本的地址）
＃配置管理可交付物（CM Deliverables）
每次都构建什么(有可能你这个项目包括很多的部分，这个时候就要特别关注这一点）
构建后，CM的产出什么
可交付物的文件格式是什么(zip包，tar包，还是iso文件）
＃配置管理构建时间表(CM Build Schedule)
此部分可以引用项目计划里边的内容，且留下项目计划的链接。
＃发布管理
发布服务器地址(每次做完构建，记得把build，log等都上传到这里来）
访问方式(network drive,ftp,http, https???，最好只提供http访问）
＃版本库服务器备份和还原计划
这部分可以单独形成文档，然后作为相关文档在配置管理计划里引用。
版本库服务器如何备份和还原,
备份计划（daily incremental, weekend full backup?)
还原计划（多少天还原一次？）
注：备份文件的验证和还原要在另外一台机器上，不要在正式的服务器上去实验。切记切记
＃发布服务器的备份和还原计划
这部分可以单独形成文档，然后作为相关文档在配置管理计划里引用。
因为发布服务器上都是数据，这个也可以交给IT部门去完成。
＃配置管理培训
这部门主要讲在项目过程中，CM可以给研发人员提供哪些培训
这部分的培训是指CM可以提供的，项目组可以根据项目情况进行选择，但是一般配置管理工具的简单使用的培训还是必须的。与其等后边出现问题了，不如项目没开始呢就给大家讲一遍。
＃附录
有什么没说话完的，这里还可以说一说，呵呵
抛砖引玉了，希望大家能踊跃发言，一起讨论，共同进步，谢谢。
出自：配置管理之路 http://bbs.scmroad.com/
版权所有，转载请注明原作者和出处，谢谢合作。
目的：这篇文章主要想和大家交流下，我们在写配置管理计划的时候都应该写些什么。写配置管理计划对于一个CM来说是一个必修课，也是一个必须修好的课程。但是很多新手都不知道如何下手。公司有模版的还好点，如果要是让一个新人从头开始为一个新项目写一个配置管理计划，那就要抓瞎了，这里我只把我想到的一些列了出来，可能有些地方不对，或者需要补充，还希望大家都能指出来。大家一起交流，共同进步，谢谢。
＃扉页
- 文档名称
- 文档的版本信息
（哪年哪月哪日哪个人修改了哪些内容，这里的哪人一般都是负责这个项目的CM,例如，v0.1, 2009.08.05, scmroad， xxx项目配置管理计划初稿）
- 审查者(一般，配置管理计划写出来后，要让相关的人员进行审查。至于审查人员则根据公司有差异）
＃内容的索引页
＃介绍部分
项目介绍（比如项目的产品名，项目名...)
项目组成员联系人(CM，PM,QM,TestManager联系人，不一定都写上，直接负责人都写上就可以了）
缩写词（告诉人家啥叫CM）
＃相关文档
这部分内容可能不同公司有不同的标准，有的公司CM plan写的很大，很全，那么这部分引用的文档就很少；而有的公司把在CM plan中比较独立的内容，单独抽出来形成了一个文档，那么这里就要作为相关文档列出来。通常应该包括以下文档
- 项目计划（project plan),
- 代码书写规范，
- 命名规范，
- 配置管理工具的简单使用文档
（不要那种什么Clearcase，Perforce， svn手册之类的，CM应该自己整理一份开发人员最经常使用的操作写出来，后边最好还要加个FAQ部分）
＃版本管理库管理
项目所在的版本库位置在哪里，地址是什么
项目组成员创建版本库访问帐号的流程，创建帐号是否需要CM Manager审批？等等
项目组成员版本库权限分配情况
标签的创建和使用管理
＃分支管理策略
介绍在这个项目中我们要利用什么样的分支管理模型。
这部分可以单独形成文档，然后作为相关文档在配置管理计划里引用。
＃构建服务器的搭建和管理
构建服务器的硬件详细说明
构建服务器的软件安装详细说明
＃项目构建
版本号管理
如何构建项目（可以由开发人员提供）
是否采用持续集成
构建脚本说明书
构建脚本（构建脚本要放到版本管理库中，可以给出构建脚本的地址）
＃配置管理可交付物（CM Deliverables）
每次都构建什么(有可能你这个项目包括很多的部分，这个时候就要特别关注这一点）
构建后，CM的产出什么
可交付物的文件格式是什么(zip包，tar包，还是iso文件）
＃配置管理构建时间表(CM Build Schedule)
此部分可以引用项目计划里边的内容，且留下项目计划的链接。
＃发布管理
发布服务器地址(每次做完构建，记得把build，log等都上传到这里来）
访问方式(network drive,ftp,http, https???，最好只提供http访问）
＃版本库服务器备份和还原计划
这部分可以单独形成文档，然后作为相关文档在配置管理计划里引用。
版本库服务器如何备份和还原,
备份计划（daily incremental, weekend full backup?)
还原计划（多少天还原一次？）
注：备份文件的验证和还原要在另外一台机器上，不要在正式的服务器上去实验。切记切记
＃发布服务器的备份和还原计划
这部分可以单独形成文档，然后作为相关文档在配置管理计划里引用。
因为发布服务器上都是数据，这个也可以交给IT部门去完成。
＃配置管理培训
这部门主要讲在项目过程中，CM可以给研发人员提供哪些培训
这部分的培训是指CM可以提供的，项目组可以根据项目情况进行选择，但是一般配置管理工具的简单使用的培训还是必须的。与其等后边出现问题了，不如项目没开始呢就给大家讲一遍。
＃附录
有什么没说话完的，这里还可以说一说，呵呵
抛砖引玉了，希望大家能踊跃发言，一起讨论，共同进步，谢谢。
