公司内部软件版本管理规范-202009

XXX公司软件版本管理规范8/17软件版本管理规范 文档编号版本号V1.0日期2020-09-14版本变更记录版本号起止日期撰写内容或变更概要说明作者/变更者审核者V1.02017-11-14新建XXXX

目录1 引言 51.1 目的 51.2 范围 52 原则 53 角色职责 64 版本管理 64.1 版本管理流程 64.1.1 部门职责及输出物 64.1.2 版本管理流程图 74.1.3 禅道项目管理流程图 84.2 版本标识方法 84.2.1 正式版本 84.2.2 内部测试版本 94.3 版本升级管理 94.3.1 版本升级原则 94.3.2 新版本发布原则 104.4 文档的存放 114.4.1 当前版本和历史版本的存放 114.4.2 开发文档的存放 114.4.3 源代码的存放 114.4.4 SQL语句的存放 114.4.5 发行文档的存放 124.5 权限控制管理 125 版本提交规则 125.1 开发交付测试要求 125.2 测试接收标准 135.3 测试中断标准（冒烟测试） 135.4 测试通过标准 136 备份管理 147 各开发组提交文档及源码以及规则 148 版本发布流程 15

引言版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理，保证任何时间都可以取到正确的版本以及版本的组合。版本控制的主要功能是记录开发过程中的每一次修改，让开发的工作可以随时检查过往历史记录和获得正确版本，是系统的成长记录。目的本文档的编制是为了规范产品管理中心、运营开发中心、产品开发中心、项目管理中心对软件产品版本的管理。范围本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容，包括：版本标识方法软件系统数据的存放文档的修改控制文档的备份制度原则软件版本发布管理应遵循以下原则：1）实施版本变更应符合以下原则之一：为满足客户新业务、新功能需求；为满足提高业务质量、提升业务性能指标和容量扩充的需求；为解决软件故障和软件稳定性、安全性、可控性问题；为了提高软件可维护性。2）版本的集成和发布应严格按照计划执行，避免随意和频繁更新版本；3)为保证软件质量，任何一个软件版本须通过版本测试后方可上线；4)所有软件版本必须通过正式渠道发布给用户，未经审批各部门和个人不得擅自向用户发布软件版本。角色职责角色职责产品负责人/部门制定版本功能，核对研发计划执行偏差；开发人员/部门确认代码完整提交；提交相关配置文件、数据库表脚本；提交发布说明；测试人员/部门确认原有BUG的是否彻底解决；对遗留缺陷做出风险评估，出具测试报告；提交上线软件程序包；BM/配置管理员（暂无）接收上线软件程序包，正式发布通知，通知开发、测试、各业务部门并附上产品发布说明；源码、文档入库、基线维护；PMO（暂无）审批上线发布计划；跟进上线过程、监督上线流程；版本管理版本管理流程部门职责及输出物部门职责说明涉及阶段输出物产品运管部1）产品运营部负责公司用户运营类的产品管理，各产品指定唯一的产品经理负责管理；2）拟定版本功能，组织需求评审，将系统原型图、UI设计图、产品需求文档提交给开发部及产品测试部；3）对产品测试部测试通过的版本做确认，提交版本给项目部；提出版本系统原型图UI设计图产品需求文档确定版本版本发布通知（邮件形式）产品管理部1）产品管理部负责公司销售类的产品管理，，各产品指定唯一的产品经理负责管理；2）拟定版本功能，组织需求评审，将系统原型图、UI设计图、产品需求文档提交给开发部及产品测试部；3）对产品测试部测试通过的版本做确认，提交版本给项目部；提出版本系统原型图UI设计图产品需求文档确定版本版本发布通知（邮件形式）开发部根据产品运营部提交的版本进行设计、开发并完成版本内测，内测通过的版本提交给产品测试部，对测试中发出的缺陷做问题修复版本开发产品测试部依据需求文档对版本功能进行验证测试，测试不通过的版本返回给开发部修复，测试通过的版本提交给产品运营部版本测试项目部将产品运营部提交的版进行发布上线发布版本版本管理流程图禅道项目管理流程图流程说明如下：1.产品经理创建产品2.产品经理创建需求3.项目经理创建项目4.项目经理确定项目要做的需求5.项目经理分解任务，指派到人6.测试人员测试，提交bug版本标识方法为了使工作规范化、统一化，各项目组实行的版本标识管理方法分为：正式版本和内部测试版本。正式版本公司发布的正规版本。以“V”开头，版本号放后。V前面增加项目名称，版本号分3节：主版本号，次版本号和内部版本号，每节之间以小数点（.）间隔。如V2.0.1表示主版本号为2，次版本号为0，内部版本号为1。产品部控制主版本号和次版本号，项目部控制内部版本号。内部测试版本公司发布的内部测试版本。以“T”开头，版本号放后。T前面增加项目名称，版本号分4节：主版本号，次版本号，内部版本号和修正版本号，每节之间以小数点（.）间隔。如V2.0.1.12表示主版本号为2，次版本号为0，内部版本号为1，修正版本号为12。产品部控制主版本号和次版本号，开发部控制内部版本号，测试部控制修正版本号。示例：版本名含义嘀嘀打饭V4.2.1正式发布版本，证联桌面为产品名称，V4.2.1为主版本号+次版本号+内部版本号。嘀嘀打饭T4.2.1.4内部测试版本，证联桌面为产品名称，V4.2.1.4为主版本号+次版本号+内部版本号+修正版本号。每次修正缺陷后，修正版本号应增加1。版本升级管理版本升级原则版本升级应严格纳入版本管理的控制之下。应当谨慎地控制版本的升级，保障高版本的向下兼容性，或提供严格定义的升级方法。在下面几种情况下，进行版本演化和升级：1、当产品发生重大修改和改进时，主版本号加1。重大修改和改进包括：平台迁移；开发工具的迁移；体系结构的变迁。2、当产品发生较小的改进或修改时，次版本号可以加1。3、对于改动量比较少的，如修改产品的错误，可增加内部版本号。内部版本号对用户来说是不可见的，只对项目部内部版本控制有用。4、记录版本升级过程。每次版本升级，都要填写版本升级记录表，记录表样例如下：版本升级记录表版本号发布日期修改文件问题简要描述发布责任人批准人备注说明：版本号：记录当前发布的版本。发布日期：该版本批准发布的日期。修改文件：版本修改记录文件，一般为版本修改日志。新版本发布原则新版本的发布包括主版本号和次版本号的升级，一般不包括内部版本号的升级。流程如下：根据项目进展情况，或者根据用户需要进行发布准备。在指定目录中，根据本次发布的版本号建立相应的子目录，将current下的所有内容拷贝至新建目录下。可在新建目录下建立readme.txt，并加入相应的内容。readme.txt文件是记录该版本与上一版本的不同，作过哪些改动。格式样例如下：增加或修改功能涉及源文件改动原因文档的存放当前版本和历史版本的存放对于源码文件，设定Current目录，存放当前正在开发与维护的源码文件，当前未发布版本的所有数据都存放在\CURRENT\下。一旦当前版本正式发行，则当前目录被修改为相应的历史目录。历史版本是指已经发行的版本，存放在相应的版本目录之下，一般不允许改动，改动需提交申请，填写原因。开发文档的存放根据各项目部自己的情况，将系统用户需求记录、总体设计文档、详细设计及数据结构文件、测试记录、用户手册等放入相应的目录下。源代码的存放源代码包括如：java，jsp，BMP，ICO等相关文件，是未经编译处理的、不能直接交付使用的产品文件以及编译产品所需的文件；联机帮助文件HLP在未生成HLP文件之前的DOC，RTF等格式的文档也视为源代码。各子系统当前的程序源文件放入相应的目录下。对于一个子系统又分多个分子系统的情况，应在该目录下分别建立几个相应的目录。SQL语句的存放各子系统SQL文件放入…..\\SQL下，对于不同的数据库，分别建立不同的子目录，如oracle、sysbase、db2等。公共SQL文件直接放入…\SQL下即可，不同数据库的特殊SQL分别放入对应的子目录下。发行文档的存放发行文档是指产品交付用户使用所必须的文件。包括：产品可执行文件，用户使用说明书，联机帮助（HLP）；资源文件（JPG，ICO等），环境配置文件等。权限控制管理为保障文档的安全性，一致性，以及防止意外修改，必须对不同的文档设置不同的访问权限。文档权限类别：只读权限，读写权限。文档类别：设计文档，源码，发行文档。用户类别：开发人员、测试人员、分析设计人员、项目经理、配置管理员、安装盘制作人员、问题及需求管理人员、用户文档编写人员等。为了控制不同的使用权限，根据要求在服务器上分别建立不同的用户，针对不同的配置项所在目录分配不同的权限。为了便于管理，应以表格的形式列出人员与管理对象的访问关系（用户权限清单）。版本提交规则开发交付测试要求提供自测报告（不限形式，可以是文档/截图/结果说明）测试的版本号；需求/设计变更版本,必须提供对应版本说明和操作说明；测试范围：需要测试哪些功能包括因修复问题导致受影响的关联功能；给出版本测试完成的具体时间；明确指定1个固定人员提交版本给测试部门（提交前需要确认打包完所有功能）；说明：按软件测试申请单统一填写。测试接收标准首次进入必须保证软件能正常安装和运行、核心和关键业务功能100%实现,并提供对应交付件；回归测试版本致命缺陷必须100%修改,严重缺陷修改率不能低于85%,总缺陷修改率不能低于80%；测试中断标准（冒烟测试）测试环境安装无法正确进行的；产品关键业务功能、性能、可靠性存在致命缺陷导致后续测试活动无法继续开展的；已修复的致命bug重现或修复时引入新的致命bug导致后续测试活动无法进行的；修改bug没有(描述不清晰)提交缺陷分析和修改方案及测试建议的；测试通过标准严重缺陷100%修复；较严重缺陷100%修复；一般缺陷修复率95%以上；轻微缺陷修复率在85%以上；测试用例执行：100%；用例通过率：不低于95%；缺陷严重级别说明见禅道。备份管理为了保证文档的最大可恢复性，要随时及定期地进行备份工作。随时备份：开发人员每天都要将自已当日修改的源文件在本地机器上进行备份。开发负责人每天要将所有源文件在本地机备份。定期备份备份周期视各产品部、事业部的具体情况而定。如果处于开发阶段，每周应对所有的源程序项进行备份，一般为每周周五；如果处于其它阶段，根据具体情况而定，但周期不能超过两周。备份要由版本管理员负责，备份原则应是保证文档的最大可恢复性。备份文件应该记录以下内容：本次备份时间，备份内容，执行人。各开发组提交文档及源码以及规则各开发组需要提交的文档名称成果描述软件需求说明书目标客户、业务流程、系统中的角色、子功能模块介绍、质量要求、界面要求系统设计说明书系统约束、开发环境、数据流程图、用例图、模块之间的关系图、类函数文件变量等命名规则、系统安全设计说明、性能分析数据库设计说明书所有表名、表设计、表ER图、生成库的sql语句、存储过程等。表及字段命名规则。用户界面设计说明书系统界面设计说明、原型图模块设计说明书编程的接口、主要的数据结构、主要算法测试用例用例名称、用例描述、输入值、希望输出值缺陷报告Bug名称、bug状态、bug紧急情况、bug处理人等测试报告界面测试报告、性能测试报告部署说明书部署环境说明、初始化的数据、注意事项、数据的迁移等安装和使用手册安装