某项目配置管理流程.docx

上传人:b****5 文档编号:6301443 上传时间:2023-01-05 格式:DOCX 页数:21 大小:669.08KB
下载 相关 举报
某项目配置管理流程.docx_第1页
第1页 / 共21页
某项目配置管理流程.docx_第2页
第2页 / 共21页
某项目配置管理流程.docx_第3页
第3页 / 共21页
某项目配置管理流程.docx_第4页
第4页 / 共21页
某项目配置管理流程.docx_第5页
第5页 / 共21页
点击查看更多>>
下载资源
资源描述

某项目配置管理流程.docx

《某项目配置管理流程.docx》由会员分享,可在线阅读,更多相关《某项目配置管理流程.docx(21页珍藏版)》请在冰豆网上搜索。

某项目配置管理流程.docx

某项目配置管理流程

编号:

 

**项目组

软件配置管理流程

V1.2

 

修订页

编号

修订内容简述

修订日期

版本号

修订人

目录

1前言1

1.1文档说明1

1.2定义1

1.3参考资料1

2配置管理总则1

3配置管理流程2

3.1立项阶段2

3.2编码阶段3

3.2.1建立本地工作区4

3.2.2建立任务分支5

3.2.3在任务分支上开发6

3.2.4定期将主干更新合并到分支7

3.3测试阶段11

3.3.1集成测试12

3.3.2验收测试14

3.3.3版本基线化16

3.3.4解决代码冲突17

3.4发布阶段20

1前言

1.1文档说明

本文档适用于**项目组,目的是统一项目组内软件配置管理流程,加强团队开发的协同性及规范性,提高软件版本管理水平,保证软件产品的完整性、一致性和可跟踪性。

1.2定义

SVN:

Subversion的简称,一个开源的版本管理工具,CVS的下一代产品。

TortoiseSVN:

Windows环境下的SVN客户端。

Firefly:

Hansky公司生产的商用版本管理工具。

PM:

项目经理

SCM:

配置管理员

SIT:

系统集成测试

UAT:

用户验收测试

1.3参考资料

《软件配置管理模式》

2配置管理总则

●版本管理服务器的用户认证不依赖于操作系统的用户系统。

●用户的密码文件在服务端应以密文形式存放。

●服务器上应存在对版本库定期进行备份的机制。

●本流程与具体的配置管理工具无关,但推荐采用Subversion(简称SVN)作为版本管理的服务端软件,因为它能较好的减少配置管理的工作量。

3配置管理流程

3.1立项阶段

●原则上,一个项目群建一个版本库。

●版本库下固定分四个区:

⏹01_Trunk主干区,项目开发主线,可编译的、稳定的。

⏹02_Branches分支区,放任务分支、测试分支,公司方配置管理员管理

⏹03_Tags基线区,项目发布基线,行方配置管理员管理

⏹04_Releases发布区,存放发布内容,下发人员管理

【示意图】

●对于同时采用了两个配置管理工具(例如SVN和Firefly)的项目,建议按不同的区来划分配置管理工具的覆盖范围,例如SVN管理主干区、分支区,Firefly管理基线区和发布区。

3.2编码阶段

3.2.1建立本地工作区

1.在Windows资源管理器右键菜单中选择“SVN检出”。

2.对于开发人员来说,只需要检出主干区(01_Trunk),检出的目录就像普通Java项目目录一样。

3.2.2建立任务分支

1.在本地工作区中,右键选中项目根目录,建立并切换到分支。

注意:

分支的名称不要有空格、中文、特殊符号,一般格式为“YYYYMMDD任务简述”。

3.2.3在任务分支上开发

1.在分支上修改文件,并及时提交,SVN上每一次提交就是一个变更集。

2.可以通过切换(Switch)完成在不同分支之间的跳转,实现个人的并行开发。

切换之前,必须将本地工作区的修改内容提交到分支上。

3.2.4定期将主干更新合并到分支

当某个任务分支的开发周期较长,应定期(如每两周)将主干发生的更新合并到分支。

1.先将本地工作区切换到任务分支:

2.右键选中项目根目录,选择合并,注意合并的源应该选择主干(01_Trunk)。

3.合并后的结果都放在本地工作区,检查本次合并到底发生了哪些变化,确认之后,将合并结果提交到分支上。

3.3测试阶段

3.3.1集成测试

1.先将项目切回到主干,然后通过分支功能,基于主干建立测试分支,并切换到测试分支。

2.与开发人员确认本次下发相关任务分支路径,通过合并功能,将任务分支的内容合并到测试分支上。

3.通过“版本库浏览器”,到分支区(02_Branches)下删除已合并的任务分支。

4.通过检查更新功能,查看本次下发共修改了哪些地方,重点关注配置文件的修改,存在疑问的地方与相关开发人员确认。

5.提交合并结果到测试分支,并通知本次下发相关的开发人员,测试分支已建立。

6.开发人员将本地工作区切换到测试分支上,测试过程中发现的bug、需求的微小修订,都直接在测试分支上修改并提交。

3.3.2验收测试

1.在得到公司方配置管理员、业务人员双方确认集成测试阶段已完成后,行方配置管理员开始接手,项目进入验收测试阶段。

配置管理员首先将本地工作区切换到主干,通过合并功能,将测试分支合并到主干。

2.基于本地工作区的代码进行打包,并将测试包部署在测试环境,通知业务人员进行验收测试。

3.3.3版本基线化

1.行方配置管理员收到业务人员验收测试已通过的信息后,将合并结果(本次下发内容)提交到主干。

2.通过“分支/标记”功能,建立版本基线。

3.在项目的发布区(04_Releases)下,增加版本目录,目录名为版本号,并将下发包放于下发目录下,并将下发内容(ear包、sql文件等)提交到SVN服务器。

3.3.4解决代码冲突

1.在合并多个任务分支的过程中,常会遇到代码冲突的情况,一般选择现场编辑冲突。

2.在TortoiseMerge的窗体中,使用F8或红框中的按钮,快速定位到冲突的位置。

召集两个分支的开发人员,决定冲突位置该用谁的内容,如下图,使用的是个贷分支的修改,商户分支的修改将被丢弃。

3.解决完所有的冲突后,点击保存,并将文件标识为“解决”状态。

3.4发布阶段

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 党团工作 > 思想汇报心得体会

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1