配置管理制度及产品发布流程

配置管理制度及产品发布流程.配置管理制度术语术语

描述

软件配置管理（CM）是在项目开发中，标识、控制和管理软件变更的一种管理。基线（Baselines）是项目开发库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线开发库（devlib）存放开发过程中需要保留的各种信息，供开发人员个人专用。开发人员对其具有编辑、修改、删除等操作权限基线库（baselib）开发库中产品经过测试小组测试后，形成一个稳定的版本，由配置管理员从开发库中将该版本提取出来，形成一个新的版本。以后的版本更新将在此基础上进行更新。所有人员对基线库的最大权限只能为只读权限。.角色和职责角色职责项目经理/质控经理确定配置项、确定配置库目录权限；审查配置库变更；项目开发过程中，监督配置库使用情况；员工离职时，配置库归档完整性审核。开发小组根据配置管理制度规范，进行配置库的日常使用测试小组从开发库中取出版本进行整合测试；负责验证代码变更及修改是否正确执行。测试小组测试通过的版本方可放入基线库。配置控制组（CCB）对项目中的变更进行管理、监控；协调开发小组、测试小组、配置管理员进行配置库的优化和管理。配置管理员负责配置库的建立、权限设置、负责培训开发人员使用配置管理工具、对配置库使用情况进行管理和监督、建立配置库基线；定期备份配置库；建立和完善配置管理制度。.配置管理范围配置管理包括以下几方面：所有研发工程文档、源代码、可执行程序，相关工具及资料等。工程文档主要指：工程立项报告、开发方案、需求分析报告、软件功能规格说明书、系统设计报告、数据库表结构、测试用例、测试报告、验收报告以及上述文档的评审记录。执行程序：包括测试人员测试的所有测试版本和正式发布版本。相关设备：主要指工程开发和运行环境〔包括硬件和软件〕，以及工程开发和测试过程中可能使用的专用仪器设备，如读卡机、扫描仪等。相关资料：主要指客户提供的行业法规，标准及其调研期间提供的业务单据，往来会议记要，，电子邮件，重要的记录等。如觉得有必要也纳入配置库的管理。.配置库的建立?配置管理方案?的制定和审核通常情况下，由软件配置管理员在工程立项以后编制?配置管理方案?；如有特殊需要，根据合同或工程要求，由软件配置管理员在某一工程或工程的某一阶段开始前制定?配置管理方案?。制定以后须经过质控经理和工程经理审批方可执行。建立配置库并设置权限工程经理到配置管理员处填写?SVN用户权限变更表?，包括员工姓名、工程名称、目录权限等，由配置管理员为相关人员设置配置权限。配置库权限设置完成之后，由配置管理员将配置库名称、访问路径、访问权限等信息以邮件方式或其它方式通知各相关人员；配置库使用人员以各自的用户名和密码访问配置库。

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

.“docs〞目录：存放工程的所有相关开发文档；“manager〞目录：通常为CCB和工程相关人员共同使用；“products〞目录；存放所有测试版本和正式发布版本。只有测试人员和配置管理员才对该目录有权限。“tags〞目录放置发布的release版本的源代码和文档，只有工程组管理人员对其具有读写权限；如有开发人员需要使用基线库，须向工程经理或部门经理提出权限需求，在领导同意之后，配置管理员设置相应的权限，并通知相应人员。“branches〞目录为有定制需求时，建立分支。注：配置库权限根据实际情况可以进行调整。.开发过程中配置库使用流程工程立项后，开发流程中的配置库使用流程如下：由配置管理员按照配置库的根本结构为工程建立版本库和设置权限。各相关人员在本地导出“trunk〞目录，在“trunk/src〞目录下新建工程或者直接将代码拷贝过来，即可进行代码的上传。如果有特殊需求或者需要并行开发两个版本，工程经理必须先和配置管理员进行协商，由配置管理员在版本库中建立分支。然后按照正常的流程进行开发。建议开发人员在本地的目录结构与版本库中保持一致，以免后期更新或提交时出现冲突.测试阶段配置库使用流程当工程进入测试阶段后，配置库的使用流程如下：由工程开发人员将源代码编译后的文件放到“trunk/bin〞目录下，同时需将如下文档：打包说明、部署说明、已完成可测试的功能模块和已经修复的bug编号，一并放在该目录下，并通知配置管理员。由配置管理员打包后将测试版本上传到“products/测试版本〞，同时在mantis中建立相应的测试版本目录，然后通知测试人员，测试人员在该目录下载后进行测试。测试人员将bug提交到mantis上的对应目录，由工程经理进行统一分配给相应开发人员，开发人员修复后在mantis中将bug状态改为“已解决〞，重复〔1〕-〔3〕。每一轮测试之后测试人员需提交测试报告到“docs/测试与验收〞，总结本次测试版本的情况。.发布阶段配置库使用流程：当测试人员给出的测试结论是“通过〞时，进入产品发布阶段。

配置管理员将通过测试的版本存放于“products/正式发布版本〞。并编写产品化说明文档，存放到“docs/产品资料〞，包括：产品版本说明；产品概要介绍；本次发布包含的文件包、文档说明；本次发布包含或者新增的功能特性说明；遗留问题及影响说明；版权声明以及其他需要说明的事项。同时，配置管理员在“tags〞目录下建立相应的文件，名称为Release_版本号_时间，存放src目录下的源代码及docs下的相关文档。

最后，由配置管理员正式发布通知。通知各相关部门的负责人并附上产品发布说明和产品介绍。.配置库变更管理假设在使用配置库的过程中需要变更配置库管理权限，包括增加、修改、删除权限都必须由工程经理到配置管理员处填写?SVN用户权限变更表?，配置管理员根据?SVN用户权限变更表?进行变更，变更之后，将变更结果通知相关人员。如果有配置项需要变更，变更申请人向CCB提交变更申请，重点说明“变更内容〞、“变更原因〞，同时需要对更改做相应的评估。CCB审批该申请，分析此变更对工程造成的影响。如果同意变更，那么安排变更任务，指定变更人，执行变更，并由配置管理员在“配置库管理报告〞中登记，以便及时跟踪各工程的配置状态。否那么终止本过程。.配置库备份配置管理员应定期做好配置库的备份和恢复试验，以防意外引起的效劳器上资料的丧失，防止给公司带来严重的损失。配置库使用标准所有立项的工程，都必须申请建立配置库。开发过程中所有文档和代码必须纳入配置库管理，假设因开发人员未按照要求纳入配置库管理造成的资料丧失或版本差异，其责任皆由开发人员承担。配置库效劳器密码只有配置管理员和质控部经理掌握，其他人如因特殊原因需要该密码，必须经过质控部经理的批准前方能获取；并在使用完密码之后，通知质控部经理和配置管理员，配置管理员及时设置新的密码，以保证效劳器资料的平安性和机密性。假设因配置管理员或质控部经理泄漏密码，而造成损失，该责任完全由密码泄漏人员承担。.3.配置库密码只能在效劳器上设置，使用人员如遗忘密码，可以与配置管理员取得联系，进行密码重置。使用人员拿到初始密码后，必须在网页上修改自己的密码。4.各配置库的使用人员必须使用各自的用户名和密码进入配置库，访问各自的配置库。各使用人员不得将自己的用户名和密码泄漏给其他人员，假设因泄露密码而引起的后果将由泄漏密码者本人承担。5.工程组成员未经工程经理同意不得更改他人的文档和代码。各工程的配置库用于工程组正式开发使用，工程组成员不得恶意对其进行修改、删除、增加等操作；假设因对SVN工具不熟悉，需要学习，可以向配置管理员提出需求，由配置管理员为其提供可以练习的配置库。6.工程经理及配置管理员负责定期检查配置库的使用情况，查看是否有员工进行无故删除或恶意修改文件的行为；并对开发人员提交的文档和代码的及时性、准确性和完整性进行检查。.7.在研发人员离职时，由其工程经理负责检查配置库，检查该人员提交的代码或文档是否完全放入配置库管理，确认版本和相应文件完整无误后，工程经理在“员工离职申请单〞中签字，该员工方可离职。同时工程经理应及时通知配置管理员，取消该人员的所有权限。假设因工程经理审核不细致造成的代码或文档移交不完整，或工程经理未及时通知配置管理员取消权限，而造成的损失，该责任完全由工程经理承担。假设因配置管理员未及时取消离职员工的权限，而造成的损失，该责任完全由配置管理员承担。8.在配置库使用时，为了防止配置库更新或提交时引起冲突，需注意：工程经理在划分模块时注意每个人的模块之间尽量不要重叠。开发人员在修改文件之前或者提交文件之前，必须先更新。.开发人员注意提交的频率，每天下班前必须提交当天修改的内容〔源代码或者文档，bin目录下的文件在下次测试前提交即可〕。对于编译没有通过的源代码，也需要提交，在提交时注明没有编译通过。开发人员提交代码时必须添加注释，说明本次提交所做的修改。使用中遇到问题不能解决时，请及时联系配置管理员。9.测试版本的提交开发人员必须严格按照进度安排，提前或准时提交测试版本；如果推迟提交，必须填写变更单，并有CCB的签字。开发人员在提交测试版本时，需考虑测试环境和开发环境的差异，保证在测试环境中的可用性，如果不能跑完根本的流程，测试人员可在mantis中提交严重性bug。10.版本发布所有版本发布必须经质控部对外发布。研发人员不能私自发布代码或应用工具给技术支持人员、客服或用户。.发布准那么所有产品必须经过质控部对外发布；所有发布的产品必须经过严格的测试，配置管理员在确认测试结果通过以后，进行产品发布的准备；所有工程在发布时，配置管理员需检查文档是否齐全，文档的编写严格按照质控发布的文档模板填写；如果有其它部门需要质控发送产品时，包括临时发布或者紧急发布的任何产品，需由需求部门填写?产品申请单?，否那么不予发送；发布完毕填写?产品发布记录表?。.经质控部对外发布的产品分为如下三种：外购产品、自研发软件和控件、SDK类。各种产品在发布前需符合一定的条件，具体如表1所示：

编号产品种类发布前准备发布过程发布后1外购产品测试报告、功能介绍、参数说明、模块介绍编写产品的使用说明（包括功能介绍、支持环境、使用方法），打包与技术支持保持联系，跟踪产品使用情况2自研发软件需求、设计、功能说明、版本说明、部署说明、测试报告编写产品的使用说明（包括功能介绍、支持环境、使用方法），打包与技术支持保持联系，跟踪产品使用情况3控件，sdk类产品的版本说明、功能介绍、函数说明、演示demo、测试报告与技术支持保持联系，跟踪产品使用情况.说明：外购产品由质控部负责测试，其它由研发部内部测试通过后再提交给质控。每种产品在发布前必须文档齐全，否那么不予发布。特殊情况，需由技术中心总监签字。发布流程客户端产品——发证洗KEY版驱动用途：用于内部发证使用。.发送内容：最新的发证洗key版，版本更新说明，发证本卷须知，是否为强制更新〔是/否〕、更新时间点：(如：10月20之前必须完成更新)。发送客服中心总监；发送办事处负责人；发送技术中心总监；抄送客服部和证书制作部经理；抄送质控部经理；技术中心助理最新版本上传到公共平台/技术部一栏，供技术中心人员下载质控部邮件发送上传至公共平台.——用户使用版证书驱动用途：用于客户使用。发送内容：驱动版本在网站上的位置，版本更新说明(重点说明解决什么问题)、适用范围〔详细明确说明此版本适用的范围〕、本卷须知〔如果没有就写“无〞〕。质控部美工放到公司网站下载中心发送客服中心总监；发送办事处负责