项目软件版本号管理规范
- 格式:doc
- 大小:120.00 KB
- 文档页数:7
项目版本管理规范一、背景介绍项目版本管理是指在软件开辟过程中,对项目代码和文档进行有效管理和控制,以确保团队成员之间的协作顺畅,并保证项目的稳定性和可靠性。
本文将介绍项目版本管理的标准格式和相关要求。
二、版本管理工具1. Git:Git是目前最流行的分布式版本控制系统,具有强大的分支管理和合并能力,适合于团队协作开辟。
2. SVN:SVN是集中式版本控制系统,适合于小型项目或者个人开辟。
三、版本管理流程1. 创建仓库:在版本管理工具中创建项目仓库,并设置相应的权限和分支策略。
2. 分支管理:根据项目需求,创建主分支(Master)和开辟分支(Develop),团队成员在开辟分支上进行开辟。
3. 版本发布:当开辟分支上的功能开辟完成并经过测试验证无误后,将其合并到主分支,并打上版本号进行发布。
4. 缺陷修复:如果在发布后发现了缺陷,可以在主分支上创建暂时分支进行修复,修复完成后合并到主分支,并打上修订版本号。
5. 版本回退:如果某个版本浮现了严重问题,可以通过版本回退的方式将代码还原到之前的稳定版本。
四、版本号规范版本号通常采用主版本号.次版本号.修订版本号的格式,例如1.0.0。
具体规范如下:1. 主版本号:当项目进行了重大的功能改变或者架构调整,且不兼容之前的版本时,主版本号加1。
2. 次版本号:当项目新增了功能或者进行了较大的优化,且兼容之前的版本时,次版本号加1。
3. 修订版本号:当项目进行了缺陷修复或者进行了小的改进,且兼容之前的版本时,修订版本号加1。
4. 预发布版本号:当项目处于开辟阶段,但已经具备部份功能时,可以在版本号后加之预发布标识,如1.0.0-alpha、1.0.0-beta等。
五、提交规范1. 提交信息:每次提交待码时,需要提供清晰明确的提交信息,包括修改的文件、修改的内容和修改的原因。
2. 提交频率:建议频繁提交待码,每一个提交尽量只包含一个功能或者一个缺陷修复,避免多个功能或者修复混合在一个提交中。
项目版本管理规范一、背景和目的项目版本管理是指对软件项目开辟过程中的不同版本进行有效管理和控制的一种方法。
通过版本管理,可以确保团队成员之间的协作顺畅,减少冲突和错误,并提高项目开辟的效率和质量。
本文旨在制定项目版本管理规范,以确保项目开辟过程中的版本管理工作得以规范和有效进行。
二、适合范围本规范适合于项目开辟过程中的版本管理工作,包括但不限于软件开辟项目、网站开辟项目等。
三、术语定义1. 版本:指软件或者项目的不同发布或者修改状态。
2. 主版本号:用于标识软件或者项目的重大改动或者功能增加。
3. 次版本号:用于标识软件或者项目的小幅改动或者功能优化。
4. 修订号:用于标识软件或者项目的错误修复或者细微调整。
5. 版本控制系统:用于管理和控制软件或者项目版本的工具或者系统,如Git、SVN等。
四、版本号命名规则1. 版本号由三部份组成:主版本号.次版本号.修订号。
2. 主版本号、次版本号、修订号均为非负整数。
3. 当进行重大改动或者功能增加时,主版本号加1,次版本号和修订号归零。
4. 当进行小幅改动或者功能优化时,次版本号加1,修订号归零。
5. 当进行错误修复或者细微调整时,修订号加1。
五、版本管理流程1. 创建版本库:在版本控制系统中创建项目的版本库,并设置合适的权限控制。
2. 初始化版本库:将项目的初始代码或者文件导入版本库,并进行首次提交。
3. 分支管理:根据项目需要,创建主分支和开辟分支。
主分支用于发布稳定版本,开辟分支用于进行功能开辟和测试。
4. 版本提交:开辟人员根据任务分配和进度,将代码或者文件提交到相应的分支中。
5. 版本合并:当开辟分支的功能开辟和测试完成后,将开辟分支合并到主分支中,并进行测试和验证。
6. 版本发布:经过测试和验证的版本,由项目负责人或者项目经理决定发布到生产环境或者客户端。
7. 版本回滚:如果发布的版本浮现问题或者不符合需求,需要及时进行版本回滚,恢复到之前的稳定版本。
项目版本管理规范一、引言在软件开发过程中,版本管理是一个重要的环节。
通过规范的版本管理,可以有效地管理软件的不同版本,追踪和记录变更,保证软件的稳定性和可追溯性。
本文旨在制定项目版本管理规范,确保项目的顺利进行。
二、版本管理工具选择根据项目的特点和需求,选择适合的版本管理工具。
常见的版本管理工具有Git、SVN等。
在选择工具时,需考虑以下因素:1. 功能性:工具是否满足项目的需求,如分支管理、合并冲突解决等。
2. 易用性:工具是否易于学习和使用,是否有友好的用户界面。
3. 可扩展性:工具是否支持插件或扩展,以满足项目未来可能的需求。
4. 社区支持:工具是否有活跃的社区和文档支持,便于解决问题和获取帮助。
三、版本库管理1. 创建版本库:在项目开始时,创建版本库用于存储项目的源代码和文档等文件。
版本库应根据项目的结构和模块进行组织,便于管理和维护。
2. 分支管理:根据项目的需要,合理划分分支,如主分支、开发分支、发布分支等。
主分支用于存储稳定的版本,开发分支用于开发新功能,发布分支用于发布正式版本。
在进行功能开发时,应基于开发分支创建新的分支,开发完成后再合并到开发分支。
3. 合并冲突解决:在分支合并过程中,可能会出现冲突。
冲突解决应由开发人员负责,确保合并后的代码没有错误和冲突。
四、版本命名规范1. 版本号命名:版本号应采用主版本号.次版本号.修订号的格式,如1.0.0。
主版本号表示重大功能改动或架构调整,次版本号表示新增功能或功能改进,修订号表示bug修复或小的改动。
2. 预发布版本:在正式发布之前,可以使用预发布版本进行测试和验证。
预发布版本的命名应在版本号后加上预发布标识,如1.0.0-rc1,表示第一个预发布版本。
3. 快照版本:在开发过程中,可以使用快照版本进行内部测试和验证。
快照版本的命名应在版本号后加上快照标识,如1.0.0-SNAPSHOT,表示快照版本。
五、变更管理1. 变更记录:对每一次变更都应进行记录,包括变更的内容、原因和责任人等。
项目版本管理规范一、引言项目版本管理是指对项目的软件代码、文档以及其他相关资源进行统一管理和控制的过程。
通过版本管理,可以确保项目团队成员之间的协同工作,提高项目的质量和效率。
本文档旨在规范项目版本管理的流程和操作,确保团队成员能够按照统一的标准进行版本管理。
二、版本管理工具选择版本管理工具是项目版本管理的重要工具,可以帮助团队成员进行代码的版本控制、冲突解决和协同工作。
在选择版本管理工具时,应根据项目的特点和团队的需求进行选择。
常用的版本管理工具包括Git、SVN等。
本文档以Git为例进行说明。
三、版本管理流程1. 代码仓库创建项目的代码仓库是存储项目代码和相关资源的地方。
在项目开始之前,应创建一个空的代码仓库,并设置相应的权限和分支策略。
2. 版本分支管理在项目中,通常会有主分支(Master)和开发分支(Develop)。
主分支用于发布稳定版本,开发分支用于团队成员进行开发工作。
每个团队成员在进行开发前,应从开发分支创建自己的特性分支(Feature Branch),并在特性分支上进行开发、测试和调试。
特性分支完成后,通过合并请求(Pull Request)将代码合并到开发分支。
3. 版本发布当开发工作完成,经过测试和验证后,可以将开发分支合并到主分支,并打上版本号进行发布。
版本号的命名应符合项目的版本命名规范。
4. 冲突解决在多人协同开发的过程中,可能会出现代码冲突的情况。
当出现冲突时,团队成员应及时进行冲突解决,确保代码的一致性和稳定性。
5. 版本回滚在某些情况下,可能需要回退到之前的某个版本。
版本回滚时,应谨慎操作,确保回滚后的代码和功能正常运行。
四、版本管理规范1. 提交规范团队成员在提交代码时,应遵循统一的提交规范,包括提交信息的格式和内容。
提交信息应包含简要的描述和相关的Issue或任务编号。
2. 分支管理规范团队成员在创建特性分支时,应使用有意义的分支名称,并及时删除不再使用的分支。
项目版本管理规范引言概述:项目版本管理是软件开辟过程中的重要环节,它能够匡助团队有效地管理和控制项目的版本,确保项目的稳定性和可追溯性。
本文将介绍项目版本管理的规范,包括版本命名规则、分支管理、变更记录、发布流程和文档管理。
一、版本命名规则:1.1 版本号命名规则:版本号普通由主版本号、次版本号和修订号组成,格式为“主版本号.次版本号.修订号”。
主版本号表示重大功能更新或者架构调整,次版本号表示新增功能或者较大的改进,修订号表示Bug修复或者小的改动。
1.2 预发布版本命名规则:预发布版本可以使用“alpha”、“beta”、“rc”等标识,表示开辟阶段、测试阶段和发布候选阶段。
1.3 版本标签命名规则:版本标签可以使用日期、里程碑、功能名称等进行命名,便于团队成员快速定位和识别不同的版本。
二、分支管理:2.1 主分支管理:主分支普通用于发布稳定版本,团队成员不能直接向主分支提交待码,只能通过合并其他分支或者发起合并请求来更新主分支。
2.2 开辟分支管理:开辟分支用于团队成员进行日常开辟工作,每一个团队成员在自己的开辟分支上进行开辟,并定期将开辟分支合并到主分支。
2.3 暂时分支管理:暂时分支用于解决紧急Bug修复或者特定功能开辟,修复完毕或者功能开辟完成后,应及时合并到开辟分支或者主分支。
三、变更记录:3.1 提交信息规范:每次代码提交都应包含故意义的提交信息,清晰地描述代码变更的内容和目的,方便团队成员和未来的维护人员了解代码的变更历史。
3.2 变更日志维护:团队应该定期维护变更日志,记录每一个版本的功能变更、Bug修复和性能优化等内容,方便项目管理和版本追溯。
3.3 版本比对和回滚:在浮现问题或者需要回滚到之前的版本时,团队应及时进行版本比对,找出问题所在,并进行相应的修复或者回滚操作,确保项目的稳定性。
四、发布流程:4.1 发布计划制定:在发布新版本之前,团队应制定详细的发布计划,包括版本号、发布日期、发布内容和测试计划等,确保发布过程有序进行。
软件开发版本控制规范详解在软件开发过程中,版本控制是非常重要的一环。
它能够帮助开发团队有效地协同工作、管理代码及项目的变更。
本文将详细介绍软件开发版本控制的规范,包括命名规则、分支管理、代码审核以及发布流程等内容。
一、命名规则在版本控制中,合理的命名规则能够使开发人员快速识别和定位不同的版本。
下面是一些常用的命名规则示例:1. 主版本号(Major Version).次版本号(Minor Version).修订号(Revision Number):例如1.0.0。
2. 年份.月份.修订号:例如2023.09.01。
3. 使用语义化版本(Semantic Versioning):例如v1.0.0-alpha.1。
团队可根据实际需要选择适合自己的命名规则,但需要确保团队成员之间的统一和沟通畅通。
二、分支管理有效的分支管理可以帮助团队并行开发不同的功能和修复bug,同时减少代码冲突的发生。
下面是一些常用的分支管理策略:1. 主分支(Master):用来保存稳定的正式版本,只能从其他分支合并,不能直接在该分支上修改代码。
2. 开发分支(Develop):用来集成各个开发人员的代码,是日常开发工作的主要分支。
3. 功能分支(Feature):用来开发新功能的分支,从开发分支上创建,开发完成后合并回开发分支。
4. 修复分支(Bugfix):用来修复线上问题的分支,从主分支上创建,修复完成后合并回主分支和开发分支。
5. 发布分支(Release):用来准备发布正式版本的分支,从开发分支上创建,进行代码审核、打包、测试等工作,完成后合并回主分支。
团队可根据具体项目和团队规模选择适合的分支管理策略,并在团队中建立相应的分支管理流程。
三、代码审核代码审核是保证软件质量的重要环节,它能够发现和纠正潜在的问题,提升代码的可维护性。
下面是一些常用的代码审核规范:1. 代码静态分析工具:使用静态代码分析工具,如Lint、SonarQube等,对代码进行自动检查,并根据检查结果进行修改。
软件版本管理规范软件版本管理规范是指对软件开发过程中的版本进行管理的一系列规定和措施。
版本管理规范的目的是为了保持软件开发过程的稳定性和可控性,确保软件的质量和可靠性。
一、版本号命名规范1. 版本号由主版本号、次版本号和修订版本号组成,格式为“主版本号.次版本号.修订版本号”。
2. 主版本号表示重大功能改变或架构改变,增1。
3. 次版本号表示新增功能或重要的bug修复,增1。
4. 修订版本号表示小的改动或bug修复,增1。
5. 版本号从1开始,多次迭代后主版本号不变,次版本号递增,修订版本号保持从1开始递增。
二、版本控制规范1. 使用版本控制工具对源代码进行管理,例如Git、SVN等。
2. 每个项目创建独立的分支,主分支用于稳定版本发布,开发分支用于功能开发和bug修复。
3. 每个开发人员在自己的独立分支上进行开发,开发完成后将代码合并到开发分支,测试通过后再合并到主分支。
4. 每个版本发布前,对代码进行全面的测试,包括单元测试、集成测试和系统测试。
三、文档管理规范1. 每个版本发布前,编写相应的版本发布说明文档,包括版本改动内容、新增功能、修复bug等。
2. 所有的文档都要进行版本管理,与代码版本相对应。
3. 每个版本发布后,要及时更新相应的文档,包括用户手册、API文档等。
四、发布规范1. 每个版本发布前,要进行严格的测试,确保软件的质量和稳定性。
2. 每个版本发布时,要记录发布日期、发布人、版本号等信息。
3. 发布后要及时更新版本控制工具,将发布的版本标记为稳定版本。
五、变更管理规范1. 每个版本开发过程中,要及时记录相关的变更信息,包括功能变更、bug修复等。
2. 对于关键的变更,要在团队内进行讨论和评审,并及时通知相关人员。
总之,软件版本管理规范是保持软件开发过程稳定和可控的重要手段。
通过合理的版本号命名、版本控制、文档管理、发布规范和变更管理,能够更好地管理软件版本,提高软件开发的效率和质量。
项目版本管理规范一、背景和目的在软件开辟过程中,版本管理是一项重要的工作,它能够确保团队成员之间的协作顺利进行,同时也能够保证软件的稳定性和可追溯性。
本文旨在制定一套项目版本管理规范,以确保项目的顺利进行和版本的可控性。
二、适合范围本规范适合于所有项目的版本管理工作,包括但不限于软件开辟项目、网站建设项目等。
三、规范内容1. 版本号命名规范1.1 版本号由主版本号、次版本号和修订号组成,格式为x.y.z,其中x、y、z 为非负整数。
1.2 主版本号(x):当项目进行了重大变更或者增加了重要功能时,主版本号加1。
1.3 次版本号(y):当项目进行了一些较小的功能变更或者增加了一些新功能时,次版本号加1。
1.4 修订号(z):当项目进行了一些bug修复或者进行了一些细微的调整时,修订号加1。
2. 版本控制工具2.1 推荐使用Git作为版本控制工具,通过Git可以对项目进行版本管理、团队协作和代码审查等操作。
2.2 所有项目成员都应熟练掌握Git的基本操作和常用命令,并按照规范进行代码提交和分支管理。
3. 分支管理3.1 主分支3.1.1 主分支(master)用于存放稳定的、可部署的版本,惟独经过测试和审核的代码才干合并到主分支。
3.1.2 主分支上的代码应该是可随时发布的版本,不允许直接在主分支上进行开辟和修改。
3.2 开辟分支3.2.1 开辟分支(develop)用于日常开辟工作,所有开辟人员都应该基于develop分支进行开辟。
3.2.2 每一个开辟人员应该在本地创建自己的开辟分支,并及时将代码推送到远程仓库。
3.3 功能分支3.3.1 功能分支(feature)用于开辟新功能或者进行较大的功能变更,每一个功能分支应该基于develop分支创建。
3.3.2 功能分支开辟完成后,应该及时合并到develop分支,并删除对应的功能分支。
3.4 修复分支3.4.1 修复分支(hotfix)用于紧急修复线上版本的bug,每一个修复分支应该基于主分支创建。
项目软件版本号管理规范编制审核批准日期日期日期2022.9.5内部资料,注意保密修订内容创建文档修订时间2022.9.5版本号V1.0修订人Revc.c 2/8一 . 目的1.1 软件版本按照一定的规则保存所有版本,避免发生版本丢失或者混淆等现象,并且可以快速准确的查找到任何版本。
1.2 软件版本规范有利于公司各部门之间的对接工作,有利于公司内部资料统一管理。
1.3 本文档是为规范研发部软件版本管理而制定的。
二 . 范围2.1 本文档为研发部软件开辟版本提供有关版本管理规范的相关内容,包括:2.2 版本标识方法及管理2.3 版本升级2.4 文档及源码的备份制度2.5 所有研发部软件工程师成员都必须遵照项目软件管理规范操作,公司内部使用按照文档及源码存放备份制度。
三 . 版本管理3.1.1 每一个归档版本都有两个版本号:内部版本号和外部版本号。
版本号使用 VP 规则, V(Version)是指外部版本号(研发测试版本), P(Patch)是指补丁版本号(可选)。
3.1.2 版本号命名: V/B+主版本号+次版本号+修订版本号+日期版本号Revc.c 3/83.2.1 主版本号:当功能模块有较大的变动,比如增加模块或者是整体架构发生变化。
此版本号由项目决定是否修改。
3.2.2 次版本号:相对于主版本号而言,次版本号的升级对应的只是局部的变动,但该局部的变动造成程序和以前版本不能兼容,或者对该程序以前的协作关系产生了破坏,或者是功能上有大的改进或者增强。
此版本号由项目决定是否修改。
3.2.3 修订版本号:普通是 Bug 的修复或者是一些小的变动或者是一些功能的扩充,要时常发布修订版,修复一个严重 Bug 即可发布一个修订版。
此版本号由项目经理决定是否修改。
3.2.4 日期版本号:用于记录修改项目的当前日期,每天对项目的修改都需要更改日期版本号。
此版本号由开辟人员决定是否修改。
如: V8.1.0.XXX (上一级版本号有变动时,下级要归零)如此时版本号为: V8.1.0.XXX ,此时为内部测试阶段3.3.1 开辟人员修复了测试人员提交的 bug 并经测试人员测试验证关闭bug 之后,发布到外网时,此时就进入了软件的下一个阶段,版本号可改为:Revc.c 4/8V8.1.1.XXXX ,如当前日期跟上一个版本号的日期不一样,版本号可改为:V8.1.1.XXX。
项目版本管理规范一、引言项目版本管理是软件开发过程中非常重要的一环,它能够确保项目团队在开发过程中能够有效地管理和控制代码版本,提高协作效率,降低错误率,保证项目的稳定性和可维护性。
本文旨在为项目版本管理提供一个标准化的规范,以确保项目团队能够按照统一的标准进行版本管理。
二、目标项目版本管理的主要目标如下:1. 确保代码的可追溯性和可回溯性,方便项目团队进行错误定位和修复。
2. 提供一个统一的代码库,方便项目团队进行代码共享和协作开发。
3. 管理项目的发布版本,确保发布版本的稳定性和可靠性。
4. 确保项目团队能够有效地进行代码分支管理,方便并行开发和版本控制。
5. 保护代码的安全性,防止未经授权的修改和分发。
三、版本管理工具项目团队应选择一款适合自身需求的版本管理工具进行版本管理,常见的版本管理工具有Git、SVN等。
以下是Git版本管理工具的使用规范:1. 代码仓库项目团队应创建一个统一的代码仓库,用于存放项目的源代码和版本信息。
代码仓库应具备以下特点:- 可访问性:项目团队成员能够方便地访问和下载代码仓库。
- 分支管理:支持创建和管理多个代码分支,方便并行开发和版本控制。
- 安全性:具备权限管理功能,防止未经授权的修改和分发。
2. 分支管理项目团队应根据实际需求,合理地进行代码分支管理。
常见的分支管理策略有主分支(master)、开发分支(develop)、功能分支(feature)、修复分支(hotfix)等。
具体规范如下:- 主分支(master):用于存放稳定的发布版本,不允许直接在此分支上进行开发和修改。
- 开发分支(develop):用于存放当前正在进行的开发版本,所有的开发工作都应在此分支上进行。
- 功能分支(feature):用于开发新功能的分支,从开发分支(develop)上创建,完成开发后合并回开发分支。
- 修复分支(hotfix):用于修复线上版本的分支,从主分支(master)上创建,修复完成后合并回主分支和开发分支。
项目软件版本号管理规范
历史修改记录
一. 目得
1.1软件版本按照一定得规则保存所有版本,避免发生版本丢失或混淆等现象,
并且可以快速准确得查找到任何版本。
1.2软件版本规范有利于公司各部门之间得对接工作,有利于公司内部资料统一
管理。
1.3本文档就是为规范研发部软件版本管理而制定得。
二. 范围
2.1本文档为研发部软件开发版本提供有关版本管理规范得相关内容,包括:2.2版本标识方法及管理
2.3版本升级
2.4文档及源码得备份制度
2.5所有研发部软件工程师成员都必须遵照项目软件管理规范操作,公司内部使
用按照文档及源码存放备份制度。
三. 版本管理
3.1版本号规则
3.1.1每个归档版本都有两个版本号:内部版本号与外部版本号。
版本号使用
VP规则,V(Version)就是指外部版本号(研发测试版本),P(Patch)就是指补丁版本号(可选)。
3.1.2版本号命名:V/B+主版本号+次版本号+修订版本号+日期版本号
3.2版本号修改规则
3.2.1主版本号:当功能模块有较大得变动,比如增加模块或就是整体架构发
生变化。
此版本号由项目决定就是否修改。
3.2.2次版本号:相对于主版本号而言,次版本号得升级对应得只就是局部得
变动,但该局部得变动造成程序与以前版本不能兼容,或者对该程序以前得协作关系产生了破坏,或者就是功能上有大得改进或增强。
此版本号由项目决定就是否修改。
3.2.3修订版本号:一般就是Bug 得修复或就是一些小得变动或就是一些功
能得扩充,要经常发布修订版,修复一个严重Bug 即可发布一个修订版。
此版本号由项目经理决定就是否修改。
3.2.4日期版本号:用于记录修改项目得当前日期,每天对项目得修改都需要
更改日期版本号。
此版本号由开发人员决定就是否修改。
如: V8、1、0、XXX (上一级版本号有变动时,下级要归零)
3.3版本号修改举例说明
如此时版本号为:V8、1、0、XXX ,此时为内部测试阶段
3、3、1 开发人员修复了测试人员提交得bug并经测试人员测试验证关闭bug 之后,发布到外网时,此时就进入了软件得下一个阶段,版本号可改为:V8、1、1、XXXX ,如当前日期跟上一个版本号得日期不一样,版本号可改为:V8、1、1、XXX。
3、3、2 如果对软件进行了一些功能上得改进或增强,进行了一些局部变动得时候要修改次版本号,如:V8、2、0、XXXX(上一级有变动时,下级要归零)。
3、3、3 当功能模块有较大变动,增加模块或整体架构发生变化时要修改主版本号,如新增加了退款功能,则版本号要改为:V9、0、0、XXXX;
3.4版本控制记录
3、4、1 版本状态变迁要遵守一定得规则,内部先生成一个内部版本,提交测试审批,生成外部版本。
(测试人员在测试过程中根据《软件测试规程》检测生成《软件测试报告》再由项目组内部讨论就是否能生成新得版本)不通过则为无效版本,需要软件开发人员再进行修改,直至通过。
通过后生成表格记录,再与源码一起打包受控形成外部版本。
3、4、2 版本审核记录表如下:每次审核记录添加,审核通过后作为开发文档一起打包受控。
3.5版本更新记录
3、5、1 版本更新软件工程师根据项目内容得变更,优化软件功能得,需要变更内部版本号提交测试审批,通过了则由开发人员进行版本归档,(测试人员在测试过程中根据项目软件变更优化得内容,结合项目软件整体结合进行测试。
测试完成根据《测试报告》由项目组内部讨论就是否能生成新得版本。
不通过则为
无效版本,由开发人员再进行优化工作。
更新记录过程中生成表格记录,审核通过后与源码一起打包受控形成外部版本。
3.6版本受控说明:
3、6、1 开发人员完成所负责模块得代码编写任务后,提交到项目经理处;3、6、2 项目经理向测试人员提交测试任务;
3、6、3 测试人员准备测试所需得环境;
3、6、4 测试人员开展测试并根据《软件测试报告》实时提交BUG;
3、6、5 开发人员处理测试过程中所出现得BUG,并提交给测试人员进行回归测试,直至BUG被解决;
3、6、6 测试基本完成后,测试人员提交测试报告;
3、6、7 根据项目市场需求结合实际情况决定就是否发布新得版本;
3、6、8 测试人员与各相关人员经讨论后确定好新版本各项信息;
3、6、9 测试人员发布新版本;
四. 版本升级
4.1版本升级原则
4.1.1版本升级应严格纳入版本管理得控制之下。
应当谨慎地控制版本得升级,
保障高版本下得兼容性,提供严格定义得升级方法。
4.1.2记录版本升级过程。
每次版本升级,都要填写版本升级记录表,记录表
样例如下:(仅供外部版本升级)内部版本与修订版本分别使用版本审核记录表、版本更新记录表。
4.2新版本得发布
4.2.1新版本得发布指对外新版本程序得升级,内部版本程序与变更版本程序
只对研发部内部升级。
流程如下:
1)根据项目进展情况,或者根据用户需要、市场需求进行发布准备。
2)将发布所需文件进行打包整理,放在指定目录中,给目录加上标签,标
签中包含将要发布得版本信息。
3)同样对源码文件也要加上与版本信息相关得标签。
五. 文档及源码存放备份制度
5.1开发文档
5.1.1各项目得开发文档根据对外新版本程序得发布做出相对应得变更,内部
版本程序与更新得程序不做变更。
5.1.2根据各项目组自己得情况,将市场需求记录、总体设计文档、详细设计
及数据结构文件、测试记录、用户手册等放入备份文件中与源代码一起打包保存。
5.2版本归入版本库
5、2、1测试与审批通过之后,由CMO(配置管理员)归入版本库,除了源文件,同时归档得有测试报告、版本配套表、升级指导书等相关文档。
5、2、2 需有内部版本FTP空间,仅内部使用;
开发:有上传/下载权限,无修改与删除选项;
测试:只有下载权限;
技术:只有下载权限;
运维/项目专员:内部版本,复制到外部版本;
同意发布后:
技术从外部版本文件夹获取版本,给客户更新;技术:只有下载权限;。