软件版本控制规范.docx
《软件版本控制规范.docx》由会员分享，可在线阅读，更多相关《软件版本控制规范.docx（9页珍藏版）》请在冰豆网上搜索。
软件版本控制规范
软件版本控制规范
RevisionHistory
Date
Version
Description
Author
2011-08-06
draft
Efun
2011-08-20
draft
调整了文档的结构，增加了版本控制相关的内容
Efun
软件版本控制规范
1目的
规范部门软件产品版本升级流程，清晰管理版本号，加强不同版本软件保存的可靠性。
2适用范围
适用于开发结束进行测试或投入应用的软件系统的升级或变更管理。
3职责
3.1开发人员
开发人员负责代码的开发，开发的代码需提交到正确的svn地址。
3.2发布人员
发布人员负责代码的发布，发布的代码需根据releasenote从svn获得，发布后需向所有相关人员发送成功的邮件，并更新JIRA上的状态。
4工作程序
4.1项目开发人员注意事项
4.1.1开发人员每天早上至少从svn上update一次代码，下班前需再次update代码后，将修改的代码commit到svn。
4.1.2开发人员更新或提交代码时如果发现有代码冲突，需立即找代码冲突的相关人员查找原因，严禁直接强制提交。
4.1.3发布代码到uat和生产机需由专门的发布人员操作，每次发布到uat和生产机，需在JIRA上登记。
4.1.4发布人员只接收releasenote，发布人员根据releasenote从svn拉下代码并打包，不接收开发人员拷贝的代码文件。
4.1.5发布代码到生产机需根据releasenote生成checklist，由开发人员和发布人员根据checklist检查无误后进行发布，releasenote和checklist的结果需在svn上留档。
4.1.6发布生产机成功后，发布人员需向所有相关人员发送成功的邮件，并更新JIRA上的状态。
4.2版本管理策略
4.2.1代码分支的管理
4.2.1.1代码分支管理示意图
参见图
图
4.2.1.2代码分支管理策略
在使用版本控制系统时，必须考虑如何设置分支结构。
可以通过镜像源代码文件来创建一个分支。
然后，可以在不影响源的情况下更改该分支。
例如，如图.1的分支结构所示，MAIN分支包含已通过集成测试的已完成功能，而DEVELOPMENT分支包含团队正在构建的代码。
当DEVELOPMENT分支中的新功能完成并可通过集成测试时，可以将代码从DEVELOPMENT分支提升到MAIN分支中。
此过程称为“反向集成”。
反之，如果将代码从MAIN分支合并到DEVELOPMENT分支中，则此过程称为“正向集成”。
图.1
分支和合并需要遵循下列原则：
1.每个分支都必须具有一个定义的策略，此策略与如何将代码集成到相应分支中有关。
例如，在图.1的分支结构中，可以指定一个团队成员来拥有和管理MAIN分支。
该成员负责执行初始分支操作、将更改从DEVELOPMENT分支反向集成到MAIN分支，以及将更改从MAIN分支正向集成到DEVELOPMENT分支。
当MAIN分支也从其他分支集成更改时，正向集成非常重要。
2.MAIN分支必须包含已通过集成测试的代码，以便始终准备进行发布。
3.由于团队成员会定期签入更改，因此DEVELOPMENT（或工作）分支将不断演变。
4.标签（tag）是分支中的文件在某个特定时间的快照。
反向集成和正向集成的频率：
反向集成和正向集成应至少在用户情景完成时进行。
虽然每个团队对于完成的定义可能不同，但完成用户情景通常意味着完成了功能和对应的单元测试。
只能在单元测试验证DEVELOPMENT分支的稳定性后反向集成到MAIN分支中。
如图.2所示。
图.2
如果具有多个工作（即DEVELOPMENT）分支，则当任意分支集成到MAIN分支时应立刻正向集成到所有工作分支。
因为MAIN分支保持稳定，所以正向集成是安全的。
工作分支中可能会发生某些冲突或失败，这是因为无法保障工作分支是稳定的。
应尽快解决所有冲突，这非常重要。
4.2.1.3添加分支的时机
以下情况下应创建分支：
•在必须按与现有分支不同的时间表/周期发布代码时。
•在代码需要不同的分支策略时。
如果创建具有新策略的新分支，则可以为项目增添策略价值。
•在向客户发布功能且团队打算进行不影响计划的发布周期的更改时。
不应对每个用户情景创建分支，因为这会产生较高的集成成本。
虽然通过可方便地进行分支，但在分支很多时，管理分支的开销可能会很大。
4.2.1.4从版本控制的角度，关于发布的管理
团队应能在任意冲刺（sprint）末尾发布代码。
可以标记（tag）一个分支以在某个特定时间点为代码拍摄快照。
如图.1所示，可以为发布标记MAIN分支。
这样，就可以将分支返回到此时间点时的状态。
注意只有已反向集成到MAIN分支的代码才能被发布。
图.1
在为发布创建分支时，应从MAIN分支（该分支最稳定）创建分支。
如果从工作分支对发布进行分支，则会导致集成问题，因为无法保证工作分支的稳定性。
4.2.1.5分支或标签（tag）的命名
版本号
Smartphone
_
代号
a
b
代号
说明
a
项目代号，首字母大写，推荐使用驼峰式命名。
b
创建日期，4位年，2位月，2位日，位数不够补0。
例：
Smartphone项目在2011年9月5日创建了一个分支，则分支命名为Smartphone_
4.2.2版本号的含义
版本号
3.
5.
0.
0
vi-update
1.
0.
0
代号
a
b
c
d
e
f
g
h
代号
说明
a
大版本号，代表一次重要的系统升级。
上线前为0，上线后从1开始计数，每一次重要的系统升级后计数加1。
b
小版本号，代表一次比较大的系统升级。
从0开始计数，每一次比较大的系统升级后计数加1。
c
次版本号，代表一次生产机系统更新，如CR，或bug的修复。
从0开始计数，每发布一次生产机后计数加1。
d
内部版本号，代表一次测试系统更新。
从0开始计数，每发布一次测试机后计数加1；次版本号计数加1时，计数归零。
e
只在非主干分支上标示，代表开发的项目代号
f
只在非主干分支上标示，对应开发的项目的第几个分支。
从1开始计数，对应开发的项目每创建一个，计数加1。
g
只在非主干分支上标示，分支次版本号，代表一次生产机系统更新，如CR，或bug的修复。
从0开始计数，每发布一次生产机后计数加1。
（一般开发分支需要合并到MAIN分支上才能发布到生产机，只有当开发分支代码独立为一套新的应用，在生产机上有新的url访问路径时，才能发布到生产机）
h
只在非主干分支上标示，分支内部版本号，代表一次测试系统更新。
从0开始计数，每发布一次测试机后计数加1；次版本号计数加1时，计数归零。
在不造成误解的前提下，沟通时分支版本号可使用简称，简称只取e、f、g、h位。
如果基于分支又打了一个分支，则版本号在原来分支的基础上再增加e、f、g、h位，以此类推。
例：
假设原来生产环境的代码在MAIN分支上，版本号为，现在有一个名为NewProject的项目，且NewProject项目在生产机有自己新的url，则：
基于MAIN分支新建的第一个开发分支的第一个测试版本为NewProject，简称NewProject第一个开发分支的第二个测试版本为NewProject，简称NewProjectNewProject测试通过后放到生产机，则第一个开发分支的生产机版本也为NewProject之后，基于新建的NewProject项目第二个开发分支的第一个测试版本为NewProject，简称NewProject第二个开发分支的第二个测试版本为NewProject，简称NewProject最后第二个开发分支的代码合并到了第一个开发分支，之前生产机累计已发布2次，对合并的代码内部测试3次通过，允许发布到生产机，则生产机最终发布版本为NewProject（生产机第3次发布，内部测试3次）
4.2.3服务器发布顺序
参见图
图
升级会员 