SN版本管理规范.docx
《SN版本管理规范.docx》由会员分享，可在线阅读，更多相关《SN版本管理规范.docx（23页珍藏版）》请在冰豆网上搜索。
SN版本管理规范
通联支付网络效劳股份
技术支持中心研发部版本管理标准
受理市场支持部
2021年1月
版本控制信息
版本
日期
拟稿和修改
说明
2021-12-6
刘志毅
拟稿发布
2021-1-7
刘志毅
增加了邮件通知
2021-1-25
刘志毅
重新编写了管理标准
2021-1-28
沈德权
补充了邮件通知接受方和上线版本的编译流程
2021-2-16
刘志毅
文档类别使用对象
文档类别
该文档是为技术支持中心提供一个版本管理标准性文件。
使用对象
该文档使用对象为技术支持中心研发部版本管理人员，以及其他相关人员。
未经许可，该文档不得提供应上述规定对象以外的人员阅读或使用。
1．引言
本文档是为标准技术支持中心研发版本管理而制定的。
本文档为研发部各人员提供有关版本管理标准的相关内容，包括：
1.版本标识方法
2.版本管理流程
3.角色定位
4.SVN常用命令说明
SVN
Svn是一个开源的版本控制系统Subversion的简称
文档
上线所需的相关文档，包括部署手册，源码修改清单列表等
脚本
上线所需的相关脚本，包括编译脚本等
SQL语句
上线所需的相关SQL语句，包括建表语句等
配置管理
标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并汇报配置的状态和更动要求，验证配置项的完整性和正确性。
软件配置
软件的具体形态在某时刻的瞬时影像。
配置项
软件配置管理的对象称为配置项，如：
源码。
基线
软件生存周期中各开发阶段末尾的标记，它的作用是把各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，使之便于检验和肯定阶段成果。
邮件效劳
需求转达，标签转达时候，需要发送邮件通知对方或者回复对方
版本控制
通过svnco把分支文件夹拷贝到开发环境进行开发，并进行版本控制
版本管理
根据需求，创立开发所需的分支
标签管理
为测试版本，上线版本创立标签
版本更新
通过svnci定期备份修改内容，或通过svnupdate更新当前所开发的源码，或通过svnmerge把主干新增内容更新至分支
版本测试
通过svnexport校验源码，进行源码的比对，测试
版本修复
对当前测试或上线版本出现的问题进行修复
版本冲突
由于修改了同一个文件，所以svnci，svnmerge以及svnup时会报错，造成了版本冲突问题。
2．版本管理
2．1版本标识方法
为了使工作标准化、统一化，各系统实行的版本标识管理方法分为：
上线版本，测试版本，修复版本，文档版本，脚本版本以及sql语句版本。
2．1．1版本标识说明
上线版本：
在生产环境上运行的正式版本。
测试版本：
在UAT环境上运行的测试版本。
修复版本：
在生产环境上用于修复当前版本的补丁版本。
以“acc〞开头，版本号放后。
版本号分2节：
主版本号为上线时间点，由3节组成，每节之间以小数点〔.〕间隔。
如acc_11.01.26表示主版本号为11.01.06，上线时间为2021年1月26日，次版本号为修复版和测试版本的组合，比方acc_11.01.26_patch1，主版本为11.01.26,次版本号为patch1，说明该版本为1次修复版本，如acc_11.01.26_test1,说明该版本为1次测试版本，如acc_11.01.26_patch1_test1，说明该版本为1次修复版本的1次测试版本。
文档版本：
上线版本对应的相关文档。
以“file〞开头，版本号放后。
就一个主版本号，为上线时间点，如file_11.01.26，指文档为上线版本11.01.26的文档。
注：
文档名必须是英文+数字组成，暂不支持中文名
脚本版本：
上线版本对应的相关脚本。
以〞spt〞
sql语句版本：
上线版本对应的sql语句。
以“sql〞为开头，版本号放后。
就一个主版本号，为上线时间点，如sql_11.01.26，指sql语句为上线版本11.01.26的sql语句。
2．2目录结构
现以其中一个库名的目录结构举例如下：
2．3目录说明
以子系统类别为主目录〔即库名〕。
库名
子系统
说明
apsbm
APSBM
apsbat
清分清算
apsms
商户效劳平台
商户效劳平台
apsrisk_back
APSRisk_Back
风险管理系统〔后台〕
apsonl
TGP
nsp
NSP
tposp
TPOSP
commfe
通讯前置
alipay
支付宝前置
bank
银行前置
apsrpt
APSRPT
统计报表
posp
POSP
test
测试使用
apms
APMS
商户管理系统
目前暂不采用SVN管理
apsrisk_front
APSRisk_Front
风险管理系统〔前端〕.NET
目前暂不采用SVN管理
trunk
主干文件夹，存放的是当前系统的最新源码
2.3.2branches
分支文件夹，存放的是当前开发和历史开发的分支文件夹的源码。
tags
标签文件夹，存放的是当前上线版本和历史版本的源码。
2.3.4files
文档文件夹，存放的是当前上线版本和历史版本的相关文档。
2.3.5script
脚本文件夹，存放的是当前上线版本和历史版本的相关脚本。
2.3.6sql
sql语句文件夹，存放的是当前上线版本和历史版本的相关sql语句。
2．4权限控制管理
为保障版本的平安性，一致性，以及防止意外修改，必须对不同的文件夹设置不同的访问权限。
文件夹权限类别：
只读权限，读写权限。
用户类别：
开发人员、测试人员、配置管理员、QA、工程经理等。
为了控制不同的使用权限，根据要求在效劳器上分别建立不同的用户，针对不同的配置项所在目录分配不同的权限。
为了便于管理，应以表格的形式列出人员与管理对象的访问关系〔用户权限清单〕。
3．更新管理〔版本升级〕
3.1版本升级原那么
版本升级应严格纳入版本管理的控制之下。
应当谨慎地控制版本的升级，保障高版本的向下兼容性，或提供严格定义的升级方法。
在下面几种情况下，进行版本演化和升级：
1.当系统有重大的需求，需要较大的改良或修改时，主版本号为新版本上线时间点。
2.当系统有重大的BUG问题时，次版本要添加patch1。
3.对于改动量比拟少的，如修复小问题之类的，可以从当前正在开发分支支中，进行改良或修改，和下一个新版本一起上线。
4.记录版本升级过程。
每次版本升级，都要填写版本升级记录表。
3.2新版本的发布
3.2.1版本管理流程说明
1.需求和上线点确认后，开发人员以邮件通知版本管理员，邮件内容包含以下要素：
上线点时间，开发系统，开发内容等。
版本管理员根据上线点，在对应的版本库下创立分支文件夹，并以邮件回复给开发人员。
2.开发人员根据版本管理员提供的分支文件名从版本库的分支文件夹内checkout到开发效劳器建立版本控制，进行程序开发。
3.开发人员开发完成后，把分支文件夹提交到版本库，然后从版本库中checkout出主干的工作拷贝，并把版本库中最新的分支文件合并至主干的工作拷贝，合并完成后，进行diff的比对，确认没问题后，最后把主干的工作拷贝提交至版本库。
4.开发人员以邮件通知版本管理员，告知当前开发的分支已经完成，并已更新至主干中，同时邮件内容必须含有：
部署手册，源码修改清单等相关文档，编译脚本，SQL语句。
版本管理员把当前主干版本创立标签文件夹，记录当前测试版本，以邮件回复给环境管理员、测试人员、开发人员、QA和工程经理，并附带相关文件。
5.环境管理员根据版本管理员提供的测试标签export至测试效劳器进行版本测试，根据部署手册，源码修改清单等文档对源码比对，部署完成后，通知测试人员做功能测试等。
6.测试完成，测试人员以邮件通知版本管理员，版本管理员把测试标签创立为上线标签，以邮件回复给开发人员、测试人员、环境管理员、QA和工程经理，并附带相关文件，准备上线。
7.核心系统：
开发人员用上线标签的源码进行编译后，再针对上线内容进行测
试，通过后，提交上线包，相关文档给运行部上线。
管理系统：
开发人员，提交测试通过的上线包，相关文档给运行部上线。
〔序号对应以下版本管理流程图〕
8.测试未通过，开发人员对代码进行二次开发，待开发完成后，重复以上步骤4-7，直至上线
紧急变更方案
触发条件：
下一个上线版本已经并入了主干，需要在下一个上线版本前插入一个补丁版本。
1.变更需求和上线点确认后，开发人员以邮件通知版本管理员，邮件内容包含以下要素：
上线点时间，开发系统，开发内容等。
版本管理员根据上线点，在对应的版本库下创立分支文件夹〔分支名为acc_xx.xx.xx_patch1〕，并以邮件回复给开发人员。
2.开发人员根据版本管理员提供的分支文件名从版本库的分支文件夹内checkout到开发效劳器建立版本控制，进行程序开发。
3.开发人员开发完成后，把分支文件夹提交到版本库，以邮件通知版本管理员，告知当前开发的分支已经完成，同时邮件内容必须含有：
部署手册，源码修改清单等相关文档，编译脚本，SQL语句。
版本管理员把分支版本创立标签文件夹，记录当前测试版本〔测试标签：
acc_xx.xx.xx_patch1_test1〕，以邮件回复给环境管理员、测试人员、开发人员、QA和工程经理，并附带相关文件。
4.环境管理员根据版本管理员提供的测试标签export至测试效劳器进行版本测试，根据部署手册，源码修改清单等文档对源码比对，部署完成后，通知测试人员做功能测试等。
5.测试完成，测试人员以邮件通知版本管理员，版本管理员把测试标签创立为上线标签，以邮件回复给开发人员、测试人员、环境管理员、QA和工程经理，并附带相关文件，准备上线。
6.上线成功后，开发人员把紧急修复的分支〔acc_xx.xx.xx_patch1〕合并入下一个上线版本的分支内,合并后无任何冲突，再提交到版本库，然后从版本库中checkout出主干的工作拷贝，并把版本库中最新的分支文件合并至主干的工作拷贝，合并完成后，进行diff的比对，确认没问题后，最后把主干的工作拷贝提交至版本库。
7.重复以上步骤4-7，直至上线
3.2.2版本管理简略流程图
3.2.3角色定位说明
开发人员需要做：
邮件效劳，版本控制，配置项，文档，脚本，SQL语句，版本更新，版本修复，版本冲突
测试人员需要做：
邮件效劳，版本编译，版本测试
版本管理人员需要做：
邮件效劳，配置管理，基线，版本管理，标签管理
3.2.4开发守那么
◆请开发人员严格执行标准中的制定的版本管理流程。
◆上线前，必须准备好相应的文档，脚本，SQL语句，以便测试人员进行正确的测试。
◆在源码开发中的修改或者改良的地方，必须增加注释局部，以便测试人员进行正确的校验
◆在多人对同一个分支开发时，需要做好定期checkin，以保证源码无冲突
◆分支完成单元测试，进行集成测试时，才可合并入主干，如果要自己做集成测试，那么可以把主干合并入分支进行测试。
◆在多个分支开发的情况下，后上线的分支必须等前上线的分支合并入主干后测试通过了，再可并入主干
◆后上线的分支必须定期从主干合并入分支文件夹，以保证当前开发的源码是以最新上线包的根底上开发的。
◆在本地的工作拷贝中合并入主干后，再用其与版本库的主干进行源码比对，确保没有任何问题之后，再checkin到版本库中。
4．备份管理
为了保证文档的最大可恢复性，要随时及定期地进行备份工作。
1、随时备份：
（1）开发人员每天都要将自已当日修改的源文件在本地机器上进行备份。
（2）开发负责人每天要将所有源文件在本地机备份。
（3）建议备份采用循环备份。
2、定期备份
（1）备份形式为硬盘备份和光盘备份。
硬盘备份时，要备份在独立的硬盘上；光盘备份时，要将光盘存放在可靠的地方。
（2）备份周期视各系统的具体情况而定。
如果处于开发阶段，每周应对所有的源程序项进行备份，一般为每周周五；如果处于其它阶段，根据具体情况而定，但周期不能超过两周。
（3）备份要由版本管理员负责，备份原那么应是保证文档的最大可恢复性。
（4）对于历史版本或某用户的特殊版本，如果无特殊原因不再进行修改的话，建议用光盘进行备份，而且应有备份盘说明文件BACKUP.TXT。
该文件应该记录以下内容：
本次备份时间，备份内容，执行人。
5．SVN常用命令说明
svncheckout
命令简写
svnco
概要
svncheckoutURL[@REV]...[PATH]
描述
从版本库取出一个工作拷贝。
改变
创立一个工作拷贝。
选项：
--revision（-r）REV
--quiet（-q）
--depthARG
--force
--acceptARG
--usernameUSER
--passwordPASS
--no-auth-cache
--non-interactive
--ignore-externals
--config-dirDIR
用途：
版本控制
例子：
$svn/apsbat/branches/
A/a
A/b
A/c
A/d
Checkedoutrevision20.
$ls
svncommit
命令简写
svnci
概要
svncommit[PATH...]
描述
将修改从工作拷贝发送到版本库。
改变
工作拷贝，版本库
选项：
--message（-m）TEXT
--file（-F）FILE
--quiet（-q）
--no-unlock
--non-recursive（-N）
--targetsFILENAME
--force-log
--usernameUSER
--passwordPASS
--no-auth-cache
--non-interactive
--encodingENC
--config-dirDIR
用途：
版本更新
例子：
$svnci–m“备注信息〞
Sendinge.dll（修改的文件）
Transmittingfiledata.
Committedrevision21.
svnupdate
命令简写
svnup
概要
svnupdate[PATH...]
描述
会把版本库的修改带到工作拷贝，如果没有给定修订版本，它会把你的工作拷贝更新到HEAD修订版本，否那么，它会把工作拷贝更新到你用--revision指定的修订版本。
为了保持同步，svnupdate也会删除所有在工作拷贝发现的无效锁定
对于每一个更新的工程开头都有一个表示所做动作的字符，这些字符有下面的意思：
A添加
D删除
U更新
C冲突
G合并
第一列的字符反映文件本身的更新，而第二列会反映文件属性的更新。
改变
工作拷贝2
选项：
--revision（-r）REV
--non-recursive（-N）
--quiet（-q）
--no-ignore
--incremental
--diff3-cmdCMD
--usernameUSER
--passwordPASS
--no-auth-cache
--non-interactive
--config-dirDIR
--ignore-externals
用途：
版本更新
例子：
$svnup
Updatedtorevision22.
svnmerge
命令简写
svnmerge
概要
svnmergesourceURL1[@N]sourceURL2[@M][WCPATH]
svnmergesourceWCPATH1@NsourceWCPATH2@M[WCPATH]
svnmerge-rN:
MSOURCE[@REV][WCPATH]（最常用）
描述
第一种和第二种形式里，源路径〔第一种是URL，第二种是工作拷贝路径〕用修订版本号N和M指定，这是要比拟的两组源文件，如果省略修订版本号，缺省是HEAD。
第三种形式，SOURCE可以是URL或者工作拷贝工程，与之对应的URL会被使用。
在修订版本号N和M的URL定义了要比拟的两组源。
WCPATH是接收变化的工作拷贝路径，如果省略WCPATH，会假定缺省值“.〞，除非源有相同根本名称与“.〞中的某一文件名字匹配：
在这种情况下，区别会应用到那个文件。
不像svndiff，合并操作在执行时会考虑文件的祖先，当你从一个分支合并到另一个分支，而这两个分支有各自重命名的文件时，这一点会非常重要。
改变
工作拷贝
选项：
--revision（-r）REV
--non-recursive（-N）
--quiet（-q）
--force
--dry-run
--diff3-cmdCMD
--ignore-ancestry
--usernameUSER
--passwordPASS
--no-auth-cache
--non-interactive
--config-dirDIR
用途：
版本更新
例子：
将一个分支合并回主干〔假定你有一份主干的工作拷贝，分支在修订版本250创立〕：
$svncosvn:
//192.168.1.29/apsbat/trunk（首先建立主干的工作拷贝）
$cdtrunk
$svnmerge-r250:
255svn:
//192.168.1.29/apsbat/branches/acc_11.01.26（比拟acc_11.01.26的250版本和255版本之间的差异，应用到主干的工作拷贝中）
Utrunk
Utrunk
Utrunk/
如果你的分支在修订版本23，你希望将主干的修改合并到分支，你可以在你的工作拷贝的分支上这样做：
$svnmerge-r23:
30
U
…
svnresolved
命令简写
svnresolved
概要
svnresolvedPATH...
描述
删除工作拷贝文件或目录的“conflicted〞状态。
这个程序不是语义上的改变冲突标志，它只是删除冲突相关的人造文件，从而重新允许提交；也就是说，它告诉Subversion冲突已经“解决了〞。
改变
工作拷贝
选项：
--targetsFILENAME
--recursive（-R）
--quiet（-q）
--config-dirDIR
用途：
版本冲突
例子：
如果你在更新时得到冲突，你的工作拷贝会产生三个新的文件：
$svnupdate
Updatedtorevision31.
$ls
C表示冲突，说明效劳器上的改动同你的改动冲突了，你需要自己手工去解决。
如果你遇到冲突，三件事你可以选择：
Ø“手动〞合并冲突文本〔检查和修改文件中的冲突标志〕。
Ø用某一个临时文件覆盖你的工作文件。
Ø运行svnrevert来放弃所有的修改。
当你解决了foo.c的冲突，并且准备提交，运行svnresolved让你的工作拷贝知道你已经完成了所有事情。
简单介绍下手工合并冲突：
这里一个简单的例子，由于不良的交流，你和同事ttl，同时编辑了sandwich.txt。
ttl提交了修改，当你准备更新你的版本，冲突发生了，我们不得不去修改sandwich.txt来解决这个问题。
首先，看一下这个文件：
Toppieceofbread
Mayonnaise
Lettuce
Tomato
Provolone
<<<<<<<.mine
Salami
Mortadella
Prosciutto
=======
Sauerkraut
GrilledChicken
>>>>>>>.r2
CreoleMustard
Bottompieceofbread
小于号、等于号和大于号串是冲突标记，并不是冲突的数据，你一定要确定这些内容在下次提交之前得到删除，前两组标志中间的内容是你在冲突区所做的修改：
<<<<<<<.mine
Salami
Mortadella
Prosciutto
=======
后两组之间的是ttl提交的修改冲突：
=======
Sauerkraut
GrilledChicken
>>>>>>>.r2
通常你并不希望只是删除冲突标志和ttl的修改—当他收到三明治时，会非常的吃惊。
所以你应该走到她的办公室或是拿起告诉ttl，你没方法从从意大利熟食店得到想要的泡菜。
一旦你们确认了提交内容后，修改文件并且删除冲突标志。
Toppieceofbread
Mayonnaise
Lettuce
Tomato
Provolone
Salami
Mortadella
Prosciutto
CreoleMustard
Bottompieceofbread
现在运行svnresolved，你已经准备好提交了：
$svncommit-m"Goaheadandusemysandwich,discardingttl'sedits."
记住，如果你修改冲突时感到混乱，你可以参考subversion生成的三个文件—包括你未作更新的文件。
你也可以使用第三方的合并工具检验这三个文件。
svnexport
命令简写
svnexport
概要
svnexport[-rREV]URL[@PEGREV][PATH]
svnexport[-rREV]PATH1[@PEGREV][PATH2]
描述
第一种从版本库导出干净工作目录树的形式是指定URL，如果指定了修订版本REV，会导出相应的版本，如果没有指定修订版本，那么会导出HEAD，导出到PATH。
如果省略PATH，URL的最后一局部会作为本地目录的名字。
从工作拷贝导出干净目录树的第二种形式是指定PATH1到PATH2，所有的本地修改将会保存，但是不再版本控制下的文件不会拷贝。
改变
本地磁盘
选项：
--revision（-r）REV
--quiet（-q）
--force
--usernameUSER
--passwordPASS
--no-auth-cache
--non-interactive
--non-recursive
--config-dirDIR
--native-eolEOL
--ignore-externals
用途：
版本测试
例子：
从版本库导出目录〔打印所有的文件和目录〕：
$svnexport
A/test
A/quiz
…
Exportedrevision15.
svnlog
命令简写
svnlog
概要
svnlog[PATH]
svnlogURL[PATH...]
描述
缺省目标是你的当前目录的路径，如果没有提供参数，svnlog会显示当
升级会员 