软件源代码版本管理与发布剖析.doc

版本号:1.1
文件编号: XWQMS-CM-TEM-01

软件源代码版本管理与发布

版本：1.0
日期： 2010-9-9

欣网视讯 | 天智互联

修订记录
日期
版次
描述
作者
审核
批准
2010-9-9
1.0
初版发布
赵渊博

目 录
修订记录 2
1. 引言 4
1.1. 目的 4
1.2. 术语 4
1.3. 参考资料 5
2. 软件版本管理 5
2.1. 版本阶段说明 5
2.2. 版本命名规范 5
2.3. 版本号修改规则 5
2.4. SVN版本库分支与合并策略 6
2.4.1. 版本库管理说明 6
2.4.2. 版本库操作说明 6
2.4.3. 各种源码变动时，版本库操作方案 7
2.4.4. 版本库发布模式 9
2.5. 版本号发布 13
2.5.1. 版本发布追踪表 13

1. 引言
1.1. 目的
该文档是配置管理计划的一部分，主要用于源代码版本管理与发布。也可用于项目配置管理与发布。该文档使项目组成员熟悉并按文档约定执行版本管理与发布。该文档列举在开发过程中会出现的开发情况，规范在开发过程中分支的类型，何时分支、何时合并。该文档根据实际项目操作实践处于不断完善中。
应该此方案最基本的前提是需要熟悉SVN客户端操作。
1.2. 术语
名称
解释
备注
Svn
Subversion的缩写，版本控制管理工具

Tsvn
tortoiseSVN的缩写，版本控制管理工具的客户端

修订版本(revision)
每一次提交修改到版本库，就会使版本库进入一个新的状态，称之为修订版本。每一个修订版本都会被赋予一个唯一的，比前一个修订版本号大一的自然数。一个新建立的版本库的修订版号为0，其中除了空的根目录外，什么都没有。

版本库（Repository）
存放修订版的数据库

本地工作拷贝（Local working copy）
修订版在本地的副本

版本的检入（Check in）
本地副本提交到服务器的版本库

检出（Check out）
从服务器的版本库中取出修订版成为本地副本

标签（Tags）
为某一日期的版本加一个名字，便于检出或发布

分支（Branches）
修订版打分支，以后可以平行修改，互不干扰

合并（Merging）
将分支的修订版合并为一个新的修订版

冲突（Conflict）
并发版本控制时防止修订版混乱的错误机制

1.3. 参考资料
《Version Control with Subversion》
《SMOP文档格式定义规范》
2. 软件版本管理
2.1. 版本阶段说明
* Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。

* Beta版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。

* RC版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。

* Release版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，

Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。
2.2. 版本命名规范
软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号+希腊字母版本号+SVN最后修订版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。例如：1.1.1.20100409_beta_334。
2.3. 版本号修改规则
主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目经理和技术主管决定是否修改。

* 子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目经理和技术主管决定是否修改。

* 阶段版本号(1)：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由技术主管决定是否修改。

* 日期版本号 (20100409):用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。

* 希腊字母版本号+SVN最后修订版本号(beta_334):此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。
2.4. SVN版本库分支与合并策略
2.4.1. 版本库管理说明
源代码版本管理采用主干和分支的开发模式，建立分支必然会涉及到合并，如果要使用主干分支方案就必须接受合并可能带来的操作繁复。
源代码的变动主要有几种：
1、建立新项目
2、修改bug
3、根据新需求增加新功能
4、项目技术方案重大变革、升级
下面分别对以上几种变动的操作方案加以说明，当然实际操作中并不局限于下面所描述的方案，做为一种建议方案，仅希望提供给大家一种管理思路。
2.4.2. 版本库操作说明
分支的合并类型
合并的工作是把主干或者分支上合并范围内的所有改动列出，并对比当前工作副本的内容，由合并者手工修改冲突，然后提交到服务器的相应目录里。如果当前工作副本是主干，则合并的范围是分支上的改动，如果工作副本是分支的，则合并范围是主干上的改动，并且一定要注意，合并的起始位置URL一定要和当前的工作副本的URL是相同的。
一、合并一个范围的版本
此类型应用最为广泛，主要是把分支中的修改合并到主干上来。在主干上点击右键选择合并，然后选择合并类型：合并一个范围的版本。合并的源URL填写的是要合并的分支的URL，待合并的版本范围如果为空，则指的是合并分支上所有的版本，即自从分支创建以来到分支当前最新版本的所有演变。如果只是选择其中一个版本，或者几个版本，那么就表示只是将制定的n个版本的变化合并到主干上。如果只是选择其中一个版本，那么表示只是选择那个版本的修改，之前或之后的修改将不被采纳。
二、复兴合并
复兴合并可以理解为是第一种合并类型的一种特例，在复兴合并中，主干可以理解为是自从开创分支之后没有任何修改，而分支是经过修改的，而且合并中分支是没有版本选择的。经过复兴合并，分支中所有的修改都会合并到主干中，合并的结果将使得分支和主干一模一样，从而可以删除分支。
三、合并两个不同的树
此类型与前两种类型不同，第一种类型可以选择分支合并的版本，主干不能选择版本；第二种类型是主干和分支都不能选择合并的版本；而这种类型则是无论是主干还是分支都可以选择合并的版本，即可以选择过去的一个主干版本与分支的某个版本进行合并。合并的时候以选择的分支版本为主，如果选择的主干版本与分支版本有不同的地方，合并时主干部分将被放弃。
起始URL：选择主干目录的URL（应当和当前工作副本的URL一致，这个是所谓的合并点）
结束URL：选择要合并的分支的URL。
起始和结束的版本：一般起始版本应当找到最后一次同步时的版本，如果从没有同步过（第一次合并），则选择创建分支时的版本，结束版本一般是最新版本，如果你不想将某些内容合并进主干的话，也可以选择一个合并点。
2.4.3. 各种源码变动时，版本库操作方案
2.4.3.1. 建立新项目的操作方案
通常建立一个新项目时，配置管理人员会根据CMMI规范给我们建立一套完整的项目配置库，类似下图

接下来，我们在源代码目录下建立2个子目录branchs和trunk，类似下图

Trunk目录代表源代码主干，在主干上的代码通常是经过测试、功能稳定、可以随时发布的项目代码
Branchs目录代表分支，通常用于功能修改
对于新建立的项目，一般会由1人或多人搭建项目代码框架。由多人搭建项目代码框架时，每个人分别在branchs下建立自己的分支，同时建立1个集成分支，用于将搭建的代码框架合并到集成分支下，类似下图

每个人在自己的工作副本中工作、提交。当在规定时期做完自己的框架搭建后，按照2.4.2描述的分支合并类型的第一种方法全部合并到集成分支上，类似下图

合并前的图

合并后的图
在集成分支上形成一个稳定的代码框架版本后，完全可以对该框架版本进行测试。如果认为此代码框架可以合并到主干上的话，同时也可以合并到主干上，如果认为有必要的话，同时也可以对此版本打tag。
例如：新建一个WEB工程项目框架，一般web项目工程都需要用户和权限管理模块，如果该框架集成了公司统一的用户和权限管理模块，完全可以做为全公司web项目工程的基线代码（当然需要统一技术框架，如：用java开始的项目统一使用开源的ssh技术框架，以php开始的项目应该是不能用）。
项目进行到这一步后，大家都在集成分支下进行共同开发。全部功能开发完成后进行测试、修改bug。稳定版本后合并到主干上并打tag。后面操作不再细述。
2.4.3.2. 根据新需求增加新功能
对于主干上已有稳定版本，需要在此版本上增加新的开发功能的操作方案，细分的话也有不少，往往会遇到各种各样的情况，是在稳定的主干版本上新增功能开发，还是建立分支开发需要根据开发周期来衡量，最主要的还是技术主管要根据需求规划好分支，即能方便开发、方便发布，又能权衡好合并带来的工作量。
举例说明：
已有稳定的主干项目A，需要在此基础上增加功能B和功能C
1、如果功能B和功能C之间无依赖、时间上功能B要先完成，则可以建立2个分支由2人及以上分别负责，分别完成后测试并分别合并到主干上，并根据需要打tag。完成功能B后即可以合并到主干上发布版本，也可以在B分支上发布版本。
2、如果功能C依赖于功能B，时间上功能B要先完成，则可以建立1个分支由1人及以上负责，完成功能B后测试并将功能B合并到主干上，发布版本。完成功能C后再测试合并到主干上，发布版本
3、做完功能B并合并到主干上了，突然说不需要功能B了，只需要功能C。此时可以在C分支上做测试、发布版本。也可以在主干上还原到合并功能B之前的版本，并将功能C合并到主干上做测试、发布版本
以上只举例说明了3项，实际过程中肯定有很多情况。无论如果变化，坚持主干-分支的开发模式的同时，也要记住，分支不能过多，分支一旦超多起来带来的可能是灾难而不是灵活开发和发布。建立分支不要超过3层。
2.4.3.3. 修改bug的操作方案
修改bug的方案，还是离不开分支操作。如果是新建立的项目，通常在分支上开发完成功能后，可以直接在此分支上修改bug，测试并合并到主干上打tag
对于已有稳定版本的项目，如果修改bug的时间不长也可以直接在主干上修改bug，也可以新建分支修改bug，最后测试合并。
2.4.3.4. 项目技术方案重大变革、升级的操作方案
对于项目技术方案重大变革、升级的操作，一方面可以重新单独建立配置库，以之前稳定的版本做为基线代码。一方面也可以在主干上建立分支，并以此分支做为变革后的主干
2.4.4. 版本库发布模式
2.4.4.1. 开发在主干上进行
开发在主干上进行，临近发布阶段，从主干分支出来，在分支上修订集成测试，系统测试所发现的bug。在分支上发布产品升级包。发布完成，分支合并到主干。此模式需要对主干上的开发周期做一定限制，在主干上开发的各功能模块需明确开始时间与大概结束的时间，开发周期需符合主干上的发布周期。
2.4.4.2. 开发在分支上进行
开发在分支上进行，分支上的开发临近结束阶段，合并到主干修订集成测试、系统测试所发现的bug。在主干上发布产品升级包。此模式下的开发周期较灵活，各功能模块自主定义开发周期，分支上的开发临近末期则合并分支上的开发至主干。如多个功能模块发布时间临近则采取先合并先收益的方式，先合并的分支，在合并过程中解决的冲突越小。
2.4.4.3. 分支的类型
2.4.4.3.1.1. 现场版本维护的分支

现场版本的维护有如下两种情况：

现场版本即为主干上最新版本如现场版本既是主干上最新的版本，从主干上最新版本分支，分支上修改完毕，合并至主干后，在主干上做集成测试，系统测试。

现场版本不是主干上最新的版本现场版本不是主干上最新的，即现场的版本属于之前的某个时期的版本，尚未更新至目前最新的。首先确定现场版本，从现场版本的基线分支，在分支上修改完毕，通过集成测试，系统测试，发布，再合并至主干。
2.4.4.3.1.2. 项目技术方案重大变革、升级
适用于对主干的重构或开发周期较长的功能开发

2.4.4.3.2. 根据新需求增加新功能
客户化分支是永远不会关闭的分支，它随着主干的不断开发一直往前推进。客户化分支的发布在客户化分支上进行。

注：客户化分支的开发难点到一个如何与主干中的开发同步的问题。
客户化分支与主干同步有两种实现方法：
通过升级包实现同步。在主干的开发过程中，会不断有升级包产生。升级包在全省范围内部署的时候。这种处理方法适用于客户化修改未发布到现场之前通过合并主干代码实现同步。在主干的开发过程中，会不断有升级包产生。对应升级包产生的代码合并到客户化分支，解决源码上的冲突，在客户化分支做该升级包的发布。这种处理方法适用于客户化修改发布到现场之后。

2.5. 版本号发布
2.5.1. 版本发布追踪表