配置管理制度及产品发布流程PPT参考课件

1、配置管理制度及产品发布流程,配置管理制度,术语,角色和职责,配置管理范围 配置管理包括以下几方面：所有研发项目文档、源代码、可执行程序，相关工具及资料等。 项目文档主要指：项目立项报告、开发计划、需求分析报告、软件功能规格说明书、系统设计报告、数据库表结构、测试用例、测试报告、验收报告以及上述文档的评审记录。 执行程序：包括测试人员测试的所有测试版本和正式发布版本。 相关设备：主要指项目开发和运行环境（包括硬件和软件），以及项目开发和测试过程中可能使用的专用仪器设备，如读卡机、扫描仪等。 相关资料：主要指客户提供的行业法规，标准及其调研期间提供的业务单据，往来会议记要，传真，电子邮件，重要的电

2、话记录等。如觉得有必要也纳入配置库的管理,配置库的建立 配置管理计划的制定和审核 通常情况下，由软件配置管理员在项目立项以后编制配置管理计划；如有特殊需要，根据合同或项目要求，由软件配置管理员在某一项目或项目的某一阶段开始前制定配置管理计划。制定以后须经过质控经理和项目经理审批方可执行。 建立配置库并设置权限 项目经理到配置管理员处填写SVN用户权限变更表，包括员工姓名、项目名称、目录权限等，由配置管理员为相关人员设置配置权限。 配置库权限设置完成之后，由配置管理员将配置库名称、访问路径、访问权限等信息以邮件方式或其它方式通知各相关人员；配置库使用人员以各自的用户名和密码访问配置库,3. 建立

3、配置库管理报告 在建立配置库后，配置管理员须同时填写配置库管理报告，及时跟踪各配置项的状态。 配置库使用 通常以项目名称作为一级目录，二级目录包括：trunk、docs、manager、products、tags，branches： “trunk”目录通常为项目组开发人员具有读写权限，其他人根据需求进行相应权限设置。该目录包含src（源代码）目录和bin目录；bin目录下存放代码编译后的dll、ocx、exe等，同时将打包说明、可测试的模块和修复的bug说明等项目文档放在该目录下,docs”目录：存放项目的所有相关开发文档； “manager”目录：通常为CCB和项目相关人员共同使用； “pr

4、oducts”目录；存放所有测试版本和正式发布版本。只有测试人员和配置管理员才对该目录有权限。 “tags”目录放置发布的release版本的源代码和文档，只有项目组管理人员对其具有读写权限；如有开发人员需要使用基线库，须向项目经理或部门经理提出权限需求，在领导同意之后，配置管理员设置相应的权限，并通知相应人员。 “branches”目录为有定制需求时，建立分支。 注：配置库权限根据实际情况可以进行调整,开发过程中配置库使用流程 项目立项后，开发流程中的配置库使用流程如下： 由配置管理员按照配置库的基本结构为项目建立版本库和设置权限。 各相关人员在本地导出“trunk”目录，在“trunk/s

5、rc”目录下新建工程或者直接将代码拷贝过来，即可进行代码的上传。 如果有特殊需求或者需要并行开发两个版本，项目经理必须先和配置管理员进行协商，由配置管理员在版本库中建立分支。然后按照正常的流程进行开发。 建议开发人员在本地的目录结构与版本库中保持一致，以免后期更新或提交时出现冲突,测试阶段配置库使用流程 当项目进入测试阶段后，配置库的使用流程如下： 由项目开发人员将源代码编译后的文件放到“trunk/bin”目录下，同时需将如下文档：打包说明、部署说明、已完成可测试的功能模块和已经修复的bug编号，一并放在该目录下，并通知配置管理员。 由配置管理员打包后将测试版本上传到“products/测试

6、版本”，同时在mantis中建立相应的测试版本目录，然后通知测试人员，测试人员在该目录下载后进行测试。 测试人员将bug提交到mantis上的对应目录，由项目经理进行统一分配给相应开发人员，开发人员修复后在mantis中将bug状态改为“已解决”，重复（1）-（3）。每一轮测试之后测试人员需提交测试报告到“docs/测试与验收”，总结本次测试版本的情况,发布阶段配置库使用流程： 当测试人员给出的测试结论是“通过”时，进入产品发布阶段。 配置管理员将通过测试的版本存放于“products/正式发布版本”。并编写产品化说明文档，存放到“docs/产品资料”，包括：产品版本说明；产品概要介绍；本次发

7、布包含的文件包、文档说明；本次发布包含或者新增的功能特性说明；遗留问题及影响说明；版权声明以及其他需要说明的事项。 同时，配置管理员在“tags”目录下建立相应的文件，名称为Release_版本号_时间，存放src目录下的源代码及docs下的相关文档。 最后，由配置管理员正式发布通知。通知各相关部门的负责人并附上产品发布说明和产品介绍,配置库变更管理 若在使用配置库的过程中需要变更配置库管理权限，包括增加、修改、删除权限都必须由项目经理到配置管理员处填写SVN用户权限变更表，配置管理员根据SVN用户权限变更表进行变更，变更之后，将变更结果通知相关人员。 如果有配置项需要变更，变更申请人向CCB

8、提交变更申请，重点说明“变更内容”、“变更原因”，同时需要对更改做相应的评估。CCB审批该申请，分析此变更对项目造成的影响。如果同意变更，则安排变更任务，指定变更人，执行变更，并由配置管理员在“配置库管理报告”中登记，以便及时跟踪各项目的配置状态。否则终止本过程,配置库备份 配置管理员应定期做好配置库的备份和恢复试验，以防意外引起的服务器上资料的丢失，避免给公司带来严重的损失。 配置库使用规范 所有立项的项目，都必须申请建立配置库。开发过程中所有文档和代码必须纳入配置库管理，若因开发人员未按照要求纳入配置库管理造成的资料丢失或版本差异，其责任皆由开发人员承担。 配置库服务器密码只有配置管理员和

9、质控部经理掌握，其他人如因特殊原因需要该密码，必须经过质控部经理的批准后方能获取；并在使用完密码之后，通知质控部经理和配置管理员，配置管理员及时设置新的密码，以保证服务器资料的安全性和机密性。若因配置管理员或质控部经理泄漏密码，而造成损失，该责任完全由密码泄漏人员承担,3. 配置库密码只能在服务器上设置，使用人员如遗忘密码，可以与配置管理员取得联系，进行密码重置。使用人员拿到初始密码后，必须在网页上修改自己的密码。 4. 各配置库的使用人员必须使用各自的用户名和密码进入配置库，访问各自的配置库。各使用人员不得将自己的用户名和密码泄漏给其他人员，若因泄露密码而引起的后果将由泄漏密码者本人承担。

10、5. 项目组成员未经项目经理同意不得更改他人的文档和代码。各项目的配置库用于项目组正式开发使用，项目组成员不得恶意对其进行修改、删除、增加等操作；若因对SVN工具不熟悉，需要学习，可以向配置管理员提出需求，由配置管理员为其提供可以练习的配置库。 6. 项目经理及配置管理员负责定期检查配置库的使用情况，查看是否有员工进行无故删除或恶意修改文件的行为；并对开发人员提交的文档和代码的及时性、准确性和完整性进行检查,7. 在研发人员离职时，由其项目经理负责检查配置库，检查该人员提交的代码或文档是否完全放入配置库管理，确认版本和相应文件完整无误后，项目经理在“员工离职申请单”中签字，该员工方可离职。同时

11、项目经理应及时通知配置管理员，取消该人员的所有权限。若因项目经理审核不细致造成的代码或文档移交不完整，或项目经理未及时通知配置管理员取消权限，而造成的损失，该责任完全由项目经理承担。若因配置管理员未及时取消离职员工的权限，而造成的损失，该责任完全由配置管理员承担。 8. 在配置库使用时，为了避免配置库更新或提交时引起冲突，需注意： 项目经理在划分模块时注意每个人的模块之间尽量不要重叠。 开发人员在修改文件之前或者提交文件之前，必须先更新,开发人员注意提交的频率，每天下班前必须提交当天修改的内容（源代码或者文档，bin目录下的文件在下次测试前提交即可）。对于编译没有通过的源代码，也需要提交，在提

12、交时注明没有编译通过。 开发人员提交代码时必须添加注释，说明本次提交所做的修改。 使用中遇到问题不能解决时，请及时联系配置管理员。 9. 测试版本的提交 开发人员必须严格按照进度安排，提前或准时提交测试版本；如果推迟提交，必须填写变更单，并有CCB的签字。 开发人员在提交测试版本时，需考虑测试环境和开发环境的差异，保证在测试环境中的可用性，如果不能跑完基本的流程，测试人员可在mantis中提交严重性bug。 10. 版本发布 所有版本发布必须经质控部对外发布。研发人员不能私自发布代码或应用工具给技术支持人员、客服或用户,发布准则 所有产品必须经过质控部对外发布； 所有发布的产品必须经过严格的测

13、试，配置管理员在确认测试结果通过以后，进行产品发布的准备； 所有项目在发布时，配置管理员需检查文档是否齐全，文档的编写严格按照质控发布的文档模板填写； 如果有其它部门需要质控发送产品时，包括临时发布或者紧急发布的任何产品，需由需求部门填写产品申请单，否则不予发送； 发布完毕填写产品发布记录表,17,经质控部对外发布的产品分为如下三种：外购产品、自研发软件和控件、SDK类。各种产品在发布前需符合一定的条件，具体如表1所示,说明： 外购产品由质控部负责测试，其它由研发部内部测试通过后再提交给质控。 每种产品在发布前必须文档齐全，否则不予发布。 特殊情况，需由技术中心总监签字。 发布流程 客户端产品发证洗KEY版驱动 用途：用于内部发证使用,发送内容：最新的发证洗key版，版本更新说明，发证注意事项，是