(完整版)软件研发版本管理

1、封面魅蝶科技研发版本管理规范v1.0(草案 )研发中心2009-2-4目录目录 .2文档类别使用对象 .31. 引言.41.1.目的 .41.2.范围 .41.3.术语定义 .41.4.版本管理工具 .51.4.1.需求文档记录表。 . 51.4.2.主版本记录表。 .51.4.3.设计文档记录表。 . 51.4.4.测试文档记录表 . 61.4.5.软件发布记录表。 .61.4.6.软件发布明细记录表。 . 62.版本管理 .72.1.版本标识方法 .72.1.1.正式版本 . 72.1.2.测试版本 .72.2.目录结构 .72.3.文档的存放 .92.3.1.当前版本和历史版本的存放 .

2、92.3.2.开发文档的存放 . 92.3.3.源代码的存放 .92.3.4.SQL 语句的存放 .92.3.5.发行文档的存放 .92.4.权限控制管理 .103.更新管理（版本升级）.103.1版本升级原则 .103.2新版本的发布 .114备份管理 .115用户版本管理 .126研发部统一管理阶段性版本.126.1阶段性版本的提交到研发部.126.2阶段性版本的发布到公司网站上.126.3各项目组新版本内部及时备份。.137版本工具的使用 .137.1研发部采用 TFS 配置管理工具 .13文档类别使用对象文档类别该文档是为广东魅蝶科技服务有限公司提供一个版本管理规范性文件。使用对象该文

3、档使用对象为广东魅蝶科技服务有限公司研发本部各部门项目经理及版本管理人员，以及其他相关人员。未经许可，该文档不得提供给上述规定对象以外的人员阅读或使用。1. 引言1.1. 目的本文档是为规范广东魅蝶科技服务有限公司研发版本管理而制定的。1.2. 范围本文档为各研发中心提供有关版本管理规范的相关内容，包括：版本标识方法软件系统数据的存放文档的修改控制文档的备份制度1.3. 术语定义TFS：Team Foundation Server（通常记作 “ TFS）”是一种为 Microsoft 产品提供 源代码管理、数据收集、 报告和项目跟踪， 而为协作软件开发的项目。 可作为独立的软件， 或 Visu

4、al Studio Team System (VSTS) 在服务器端后端平台。VS：Microsoft Visual Studio（简称 VS ）是美国 微软公司 的开发 工具 包系列 产品 。VS 是一个基本完整的开发工具集， 它包括了整个 软件生命周期 中所需要的大部分工具， 如 UML 工具、代码管控工具、集成开发环境 (IDE) 等等。所写的目标代码适用于微软支持的所有平台文档：一种数据媒体和其上所记录的数据。配置管理：标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。软件配置：软件的具体形态在某时刻的

5、瞬时影像。配置项：软件配置管理的对象称为配置项，如：系统规格说明书， 项目开发计划， 用户手册，源码。基线：软件生存周期中各开发阶段末尾的标记， 它的作用是把各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，使之便于检验和肯定阶段成果。1.4. 版本管理工具需求文档记录表。版序拟稿审核批准发布日期v0.1××××××××××2013/1/1v0.2v0.3v1.0××××说明：版序： <主版本号 >.<次版本号 >，主版本

6、号：文档已经定版。次版本号对应主版本补充需求。次版本只对主版本功能需求的补充。当主版本号为1.0 标志项目正式立项。主版本记录表。项目名称：项目开发名称：版序建稿日期建项日期最新发布日期封存日期v12013/10/102013/11/112014/1/12014/1/1v2说明：主版本版序控制记录是将需求与项目源码进行对于管理的核心。需求文档的版序主版本号大于 1 的版本。每一个主版本对应一个TFS 源代码分支。设计文档记录表。版序拟稿审核批准发布日期研发中心李四2014/1/1说明：版序： <主版本号 >.< 次版本号 >.< 设计版本号 >测试文档记录表

7、版序拟稿审核拟稿日期执行日期质量管理部龙八说明：版序： <主版本号 >.< 次版本号 >.T< 测试版本号 >,测试版本号主要对应测试。软件发布记录表。文件版本号产品版本号发布流水号编译人审核人类型<YYYYMM00>说明：文件版本号、产品版本号:以主运行程序的文件版本号、产品版本号为准。类型：增量、全部。发布流水号：每次对外发布均有一个流水号格式为：年月+2 位数字。如：20140501软件发布明细记录表。格式详见：软件发布明细记录表.docx2. 版本管理2.1. 版本标识方法为了使工作规范化、统一化，各项目组实行的版本标识管理方法以版本号为

8、线索,将软件开发的整个生命周期.软件版序格式 : <主版本号 >.<次版本号 >.<设计版本号 >.<修订号 >软件版序记录位置 : 项目 AssemblyInfo.cs 里assembly: AssemblyTitle(" 项目名称 ")assembly: AssemblyDescription(" 项目描述 ")assembly: AssemblyCompany(" 广东南方海岸科技服务有限公司")assembly: AssemblyProduct(" 项目开发名称&quo

9、t;)assembly: AssemblyCopyright("Copyright ?2013")assembly: AssemblyVersion("< 主版本号 >.<次版本号 >.< 设计版本号 >.<修订号 >")assembly: AssemblyFileVersion("< 主版本号 >.<次版本号 >.<设计版本号 >.< 修订号 >.< 生成号 >")如何对已发布的版本进行人工校验跟踪：如图(图 1)：(图 1)

10、选中需要校验的 DLL 或 EXE -> 右键 -> 属性 -> 详细信息。正式版本所有上线至正式生产环境或客户已经验收的项目均为正式版本。测试版本所有上线至测试环境或客户试运行的项目均为测试版本。2.2. 目录结构统一的目录结构是版本管理的其中一个重要环节，对各个版本管理工具、管理软件的有效联系。目录结构图：根目录一级目录二级目录以项目开项目开发源码发名称为名称Source目录名 ;+如：主版本号NFHA.CI（ NFHA.I.DLZCII.DLZv1.0 ）文档DOC发布Releases主版本记录表.doc例子：三级目录说明项目源代码VS 项目源码（ src）类库第三方类

11、库或本公司的公共类库（ lib ）数据库SQL 文件（ DataBase）需求文档用户需求记录设计文档总体设计文档数据库 ER，数据字典等详细设计文档、UML 、网络拓扑等测试文档测试用例等其他用户使用手册产品说明书等其他项目计划实施手册需求文档记录表.doc设计文档记录表.doc测试文档记录表.doc流水号 1三级目录由以下2 个文件组成流水号 2ReleaseFile.Zip流水号 3软件发布明细记录表.docx软件发布记录表.doc2.3. 文档的存放所有的文档、代码均通过TFS 进行管理。当前版本和历史版本的存放对于源码文件。一旦当前版本创建出一个新的版本分支，则当前目录需要对权限进行

12、细分，新功能源码、文档等均迁移到新版本分支， 。历史版本是指已经发行的版本，存放在相应的版本目录之下，一般不允许改动，除非是对旧有版本的 bug 修复。开发文档的存放根据各项目部自己的情况，将系统用户需求记录、总体设计文档、详细设计及数据结构文件、测试记录、用户手册等放入相应的目录下。源代码的存放源代码包括如： java，jsp，BMP ，ICO 等相关文件，是未经编译处理的、不能直接交付使用的产品文件以及编译产品所需的文件；联机帮助文件 HLP 在未生成 HLP 文件之前的 DOC， RTF 等格式的文档也视为源代码。各子系统当前的程序源文件放入相应的目录下。对于一个子系统又分多个分子系统的

13、情况，应在该目录下分别建立几个相应的目录。语句的存放各子系统 SQL 文件放入 SourceDataBase下，公共 SQL 文件直接放入 SourceDataBase下即可，如果该项目跨多个不同的数据库，分别建立不同的子目录，如 oracle、sysbase、db2、MSSQL 等。不同数据库的特殊 SQL 分别放入对应的子目录下。发行文档的存放发行文档是指产品交付用户使用所必须的文件。包括：产品可执行文件，用户使用说明书，联机帮助（ HLP）；资源文件（ BMP ，ICO 等），环境配置文件等。以上文档作为制作成ReleaseFile.Zip ，并且填写软件发布明细记录表签入至对应的Rel

14、eases目录下，签出软件发布记录表，编辑相应内容。2.4. 权限控制管理为保障文档的安全性，一致性，以及防止意外修改，必须对不同的文档设置不同的访问权限。文档权限类别：只读权限，读写权限。文档类别：设计文档，源码，发行文档。用户类别：开发人员、测试人员、分析设计人员、项目经理、配置管理员、安装盘制作人员、问题及需求管理人员、用户文档编写人员等。为了控制不同的使用权限，根据要求在服务器上分别建立不同的用户，针对不同的配置项所在目录分配不同的权限。为了便于管理，应以表格的形式列出人员与管理对象的访问关系（用户权限清单）。3. 更新管理（版本升级）3.1 版本升级原则版本升级应严格纳入版本管理的控

15、制之下。应当谨慎地控制版本的升级，保障高版本的向下兼容性，或提供严格定义的升级方法。在下面几种情况下，进行版本演化和升级：1、当产品发生重大修改和改进时，主版本号加1。重大修改和改进包括：1）平台迁移；2）开发工具的迁移；3）体系结构的变迁。2、当产品发生较小的改进或修改时，次版本号可以加1。3、对于改动量比较少的，如修改产品的错误，可增加内部版本号。内部版本号对用户来说是不可见的，只对项目部内部版本控制有用。4、记录版本升级过程。 每次版本升级， 都要填写版本升级记录表， 记录表样例如下：版本升级记录表版本号发布日期修改文件问题简要描述发布责任人批准人备注说明：版本号：记录当前发布的版本。发

16、布日期：该版本批准发布的日期。修改文件：版本修改记录文件，一般为版本修改日志。3.2 新版本的发布新版本的发布包括主版本号和次版本号的升级，一般不包括内部版本号的升级。流程如下：1、根据项目进展情况，或者根据用户需要进行发布准备。2、在指定目录中，根据本次发布的版本号建立相应的子目录，将current 下的所有内容拷贝至新建目录下。3、可在新建目录下建立readme.txt，并加入相应的内容。readme.txt文件是记录该版本与上一版本的不同，作过哪些改动。格式样例如下：增加或修改功能涉及源文件改动原因4备份管理为了保证文档的最大可恢复性，要随时及定期地进行备份工作。1、随时备份：（1） 开

17、发人员每天都要将自已当日修改的源文件在本地机器上进行备份。（2） 开发负责人每天要将所有源文件在本地机备份。（3） 建议备份采用循环备份。2、定期备份（1） 备份形式为硬盘备份和光盘备份。硬盘备份时，要备份在独立的硬盘上；光盘备份时，要将光盘存放在可靠的地方。（2） 备份周期视各产品部、事业部的具体情况而定。如果处于开发阶段，每周应对所有的源程序项进行备份， 一般为每周周五； 如果处于其它阶段，根据具体情况而定，但周期不能超过两周。（3） 备份要由版本管理员负责，备份原则应是保证文档的最大可恢复性。（4） 对于历史版本或某用户的特殊版本， 如果无特殊原因不再进行修改的话，建议用光盘进行备份，

18、而且应有备份盘说明文件 BACKUP.TXT 。该文件应该记录以下内容：本次备份时间，备份内容，执行人。5用户版本管理目前主要以做项目为主，是根据客户要求开发的程序。为了更好地管理源程序，应为每一用户建立一个用户版本文件，该文件应包含以下内容：用户编号：用户名称：软件版本号：开始使用时间：联系人：联系电话：用户程序更改日志样例如下：更改时间版本号修改模块名称变更原因变更概述软件位置变更人员备注说明：1）用户购买软件时要为该用户建立一个包含上述内容的一个用户版本文件，并填写有关数据。2）用户进行版本更新时要求填写该文件的版本变更记录，用以反映用户版本的变更情况。6研发部统一管理阶段性版本6.1 阶段性版本的提交到研发部当各项目组更新了新版本以后，如果次版本号发生改变，各项目组配置管理员经项目经理批准后要把次版本修改的内容 （提交的内容分为修改的源码、 新的文档和安装盘）提交给研发