LISCM版本管理操作指南.docx

LISCM版本管理操作指南.docx

《LISCM版本管理操作指南.docx》由会员分享，可在线阅读，更多相关《LISCM版本管理操作指南.docx（9页珍藏版）》请在冰点文库上搜索。

LISCM版本管理操作指南

版本管理操作指南

中科软科技股份有限公司

2013年05月

关于本文档

主题

版本管理操作指南

说　　明

本文档说明了版本发布流程与规范

适用对象

项目经理、开发人员、配置人员、测试人员

修订历史

版本

章节

类型

日期

作者

说明

1.0

C

2013-05-18

刘凤丽

执行规范

说明：

类型－创建（C）、修改（U）、删除（D）、增加（A）；

目录

关于本文档2

1版本管理工具4

版本管理工具：

VSS4

2人员角色4

3环境说明5

4版本发布5

4.1发布新需求的处理方式6

4.1.1新需求提交SIT环境6

4.1.2新需求提交UAT环境6

4.1.3新需求提交PRO环境6

4.2发布BUG的处理方式7

4.2.1SIT环境BUG的处理方式7

4.2.2UAT环境BUG的处理方式7

4.2.3PRO环境BUG、运维的处理方式7

4.3注意事项7

4.4更新说明8

5与IT部的交接（只适用于版本管理人员）8

6各个环节的质量监控9

1版本管理工具

版本管理工具：

VSS

VSS主要采用独占模式（check_out，modify，check_in），也可以使用（mutil_check_out，modify，check_in，merge）模式。

在SourceSafe使用中独占模式使用的比较为成熟和普遍，独占模式要求每个人都必须在改动文件之前做签出（check_out）标志，并且标志后的文件无法被其他人修改，即文件被独占了，在完成修改后要及时签入（check_in），释放修改权。

check_in和check_out也是人们对版本控制最开始的印象。

VSS的基本特点：

1）保存修改记录：

保存了所有文件的修改历史，并可以建立分支；

2）协作与串行：

使用lock-modify-unlock的串行的工作模式，即文件被独占。

使用VSS的好处：

1）操作使用简单；

2）对硬件配置要求不高；

3）VSS备份/恢复非常简单；

4）有良好的可扩展性。

2人员角色

项目的整个实施过程中涉及到多种人员角色，而且在实际操作中各种角色的权限各不相同。

人员角色和职责：

（1）项目经理

项目经理对项目的计划进行制定、进展进行跟踪，并审核所有的需求变更和任务下发。

（2）开发人员

开发人员对项目中所有的变更进行修改，保证产品的高质量开发。

（3）测试人员

为达到客户的要求对软件产品进行的测试，对问题修复后的复测。

（4）需求人员

对客户的需求进行分析并形成文档。

（5）配置管理员

对程序的变更升级进行操作；对程序的发布、数据库变更等进行操作。

3环境说明

（1）DEV环境：

开发人员本地进行开发调试的环境；

（2）SIT环境：

中科软内部测试环境；

（3）UAT环境：

用户测试环境；

（4）PRO环境：

正式环境即客户实际操作的真实环境。

4版本发布

版本发布流程图

上述流程图中使用图形说明：

表示进程；

表示文档或实体文件包；

表示判定；

表示流向。

4.1发布新需求的处理方式

4.1.1新需求提交SIT环境

（1）开发团队在开发环境中根据开发计划，按照用户需求进行开发；提交SIT环境的时间必须是开发计划定制的时间段内，不能提前提交开发的功能点上SIT环境。

开发人员通过提交《功能点清单.xls》、《文件列表.xml》。

（2）配置管理员根据《功能点清单.xls》、《文件列表.xml》信息将本次版本的功能点发布至SIT环境，并将发布的代码更新到SIT源码库中；

（3）配置管理员发布完毕后通知SIT测试人员进行测试；

SIT发布周期为每天三次，发布时间点为上午11：

00、17：

00、22：

00。

4.1.2新需求提交UAT环境

（1）SIT测试通过后，SIT测试负责人通知配置管理员（中科软）SIT测试通过。

配置管理员根据《功能点清单.xls》、《文件列表.xml》、《冲突报告.txt》汇总待发布UAT的文件（该文件来源于SIT源码库）并提交给工行配置管理员,同时提交《功能点清单.xls》、《发布申请单.doc》。

（2）配置管理员（中科软）将提交到UAT环境的文件更新至UAT源码库。

（3）工行配置管理员验证待发布UAT包，验证通过后提交给IT部配置管理员发布；同时提交《功能点清单.xls》、《发布申请单.doc》。

（4）IT部配置管理员发布该版本到UAT环境，通知用户测试，并提供《功能点清单.xls》给用户。

UAT发布周期为每天两次，提交时间点为09：

00，15：

00。

4.1.3新需求提交PRO环境

（1）用户在UAT环境测试，测试完毕后将测试通过的功能点清单反馈给IT负责人（软件开发经理），由IT负责人审核后通知工行配置管理员。

工行配置管理员根据功能点汇总本次版本待上线文件（SQL为差分包，应用程序为全量包）提交给IT配置管理员；

（2）工行配置管理员将提交到PRO环境的文件更新至PRO代码库。

（3）IT部配置管理员发布该版本到线上环境，该版本正式生效，用户正常使用。

版本发布周期为一月发布一次。

备注：

紧急版本更新流程跟正常版本更新流程一样，只是版本周期比较短。

4.2发布BUG的处理方式

4.2.1SIT环境BUG的处理方式

（1）开发人员通过Mantis管理控制台查看SIT测试人员提出的BUG，根据BUG的紧急程度来处理，优先处理紧急的BUG。

开发人员直接修改开发源码，修改测试完毕后提交SIT环境，提交方式同“新需求提交SIT环境”流程。

（2）配置管理员发布至SIT环境后通知测试组，复测通过后将Mantis平台上BUG状态修改为“已关闭”。

备注：

SITBUG发布频次同新需求提交SIT环境；SIT环境如发现的阻断性BUG可紧急（紧急更新需项目负责人与测试负责人确认）更新到SIT环境，处理流程同SIT环境BUG处理方式。

4.2.2UAT环境BUG的处理方式

（1）开发人员通过UAT环境的Mantis管理控制台查看用户提出的BUG，根据BUG的紧急程度来处理，优先处理紧急的BUG。

该BUG的处理方式同SITBUG处理方式。

（2）配置管理员提交UATBUG至UAT环境的过程同“新需求提交UAT环境”。

用户测试通过后将BUG状态修改为“已关闭”。

UATBUG发布频次为每天两次，提交时间点为09：

00，15：

00。

4.2.3PRO环境BUG、运维的处理方式

无。

4.3注意事项

为保证发布流程的正确性，必须严格遵循下列几点：

1.开发团队需遵循用户确认的开发计划以及开发规范（包括所有文档的编写），严格遵照与客户确认的开发周期完成任务，保证了后续版本发布的正常流程。

2.开发团队成员不能修改自己或他人机器的IP地址。

3.开发团队成员不能修改JDK版本，必须使用JDK1.6版本。

4.开发团队成员不能直接修改PDM以及对应的schema文件。

5.开发团队成员不能直接修改应用程序中对应的jar包。

6.开发团队成员不能随意使用他人VSS帐号进行提交文件。

7.开发团队成员不允许更新SIT、UAT数据库。

4.4更新说明

1、开发环境的应用更新/数据库修改全部由中科软配置管理员负责；

2、SIT环境的应用更新/数据库修改全部由中科软配置管理员负责；

3、UAT环境的应用更新/数据库修改全部由IT配置岗负责；

4、线上环境的应用更新/数据库修改全部由IT配置岗负责。

5与IT部的交接（只适用于版本管理人员）

1）每个版本的更新文件在SIT环境测试通过后，需要将所有的更新和补丁文件汇总，做为UAT更新包提交给工行。

2）UAT更新包的命名应遵循以下命名规范

UAT更新包的命名为：

提交时间-待更新的环境-NEW，如200608101700-UAT-NEW

UAT更新包的邮件主题名：

提交时间-待更新的环境-NEW，如200608101700-UAT-NEW

UAT补丁包的命名为：

提交时间-待更新的环境-BUG，如200608101920-UAT-BUG

UAT补丁包的邮件主题名：

提交时间-待更新的环境-BUG，如200608101920-UAT-BUG

3）生产更新包的命名应遵循以下命名规范：

生产更新包的命名为：

提交时间-待更新的环境-NEW，如200608101700-PRO-NEW

生产更新包的邮件主题名：

提交时间-待更新的环境-NEW，如200608101700-PRO-NEW

4）紧急更新包的命名遵循以下规范：

紧急更新标识（固定使用大写字母U）-紧急更新编号-提交时间-提交人-待更新的环境，如200608101700-PRO-BUG或200608101700-PRO-BUG-mantis101

6各个环节的质量监控

开发环节是决定整个系统质量的关键环节，需要通过加强文档评审，代码评审以及对开发工程师的培训等途径，来规避错误，提升所开发功能的质量。

与之配套的，需要项目经理与开发组长一起制定评审的范围，评审的标准，并且定期抽检。