基于SVN的项目管理——集中与分散

140次阅读

共计 4210 个字符，预计需要花费 11 分钟才能阅读完成。

我们在此处不讨论 GIT 比 SVN 好多少，也不讨论 Maven 和 Gradle 哪个好用，基于现有的开发环境，大多数公司还是采用 SVN + Maven 来进行项目管理——因为这已经满足了大多数的代码管理需求，并且对于一个成熟的公司来讲，项目管理工具的改变可能需要很大的成本和决心，基于 GIT 的项目管理将会在以后详细介绍。

做程序开发和项目管理的老银棍们肯定知道，基于 SVN 的项目开发管理有两种方式：集中式开发和分散式开发，对应正常的语言描述来讲，集中式开发对应的是基于 trunk 进行开发，而分散式开发对应的就是基于 branches 进行开发。两者并没有绝对的好坏之分，具体采用哪种方式，完全凭个人喜好、项目架构和公司规定进行选择。

基于 SVN 的项目管理——集中与分散

基于主干的开发方式可能是比较主流的开发方式，三个目录的主要定义如下：

trunk：开发工程（非稳定）

tag：我们认为稳定的发布包

branches：BUG、需求变更分支

用语言描述一下开发步骤：在 trunk 中新建一个项目，此时版本号是 1.0.0-SNAPSHOT，分配权限给所有的开发人员，所有开发人员功能开发完毕之后提交代码到 trunk，测试基于 trunk 进行测试，此时 trunk 处于锁定状态——不允许再在 trunk 上进行新功能的开发，测试完毕之后打 tag，至此 1.0.0-RELEASE 版本正式发布，trunk 中的版本号变为 1.1.0-SNAPSHOT，解锁 Trunk，所有开发人员开始开发 1.1.0-SNAPSHOT，此时如果发生未测出来的 BUG 和需求变动，基于 1.0.0-RELEASE 的 tag 打分支 1.0.0-PATCH，所有相关开发人员对 1.0.0-PATCH 进行维护开发，同时主干的 1.1.0-SNAPSHOT 也在同步进行。

基于 SVN 的项目管理——集中与分散

这里很多人会问，如何将 1.0.0-PATCH 中的代码合并到 1.1.0-SNAPSHOT 中？这里用一个场景来具体描述

程序员小张负责用户注册模块的开发，在整个项目 1.0.0-RELEASE 发布之后，1.1.0-SNAPSHOT 中小张需要对注册模块进行一个升级，此时（注意，代码 没有正式开始编写），在线上运行的 1.0.0-RELEASE 版本发现了一个隐秘的 BUG（可能是代码 BUG，也可能是业务 BUG），小张需要先为 1.0.0-RELEASE 这个 tag 打出一个分支 1.0.0-PATCH-01 对这个 BUG 进行修复，修复完毕之后，将 1.0.0-PATCH-01 合并到主干中，生成版本 1.0.1-SNAPSHOT，然后发布到 Tag 中，此时 Tags 中包含 1.0.0-RELEASE 和 1.0.1-RELEASE 两个 tag，之后，进行新版本 1.1.0-SNAPSHOT 的开发——这是最好的结果。

但是事实并非如人所愿，我们最常遇到的情况是 1.1.0-SNAPSHOT 已经开发了一段时间，此时发现了 1.0.0-RELASE 中的这个隐藏 BUG，需要紧急修复，我们这里同样用一个场景来具体描述。

程序员小张负责用户注册模块的开发，在整个项目 1.0.0-RELEASE 发布之后，1.1.0-SNAPSHOT 中小张需要对注册模块进行一个升级，此时（注意，代码 已经正式开始编写 ），在线上运行的 1.0.0-RELEASE 版本发现了一个隐秘的 BUG（可能是代码 BUG，也可能是业务 BUG），小张需要先为 1.0.0-RELEASE 这个 tag 打出一个分支 1.0.0-PATCH-01 对这个 BUG 进行修复，修复完毕之后，将 1.0.0-PATCH-01 单独上线，接下来的故事就比较复杂了，小张需要将 1.0.0-PATCH-01 中的代码手动的与正在开发的 1.1.0-SNAPSHOT 进行一个合并——这是常见但是异常的结果

为什么说第二个场景属于常见但是异常，这非常考验整个 PMO 管理——为什么会出现紧急 BUG？为什么需要紧急上线？这会造成两个最直接的麻烦：

1. 线上版本不是 RELEASE 版本的，而是一个分支 PATCH。

2. 将 PATCH 中的代码合并到正在开发的代码中会异常痛苦。

如果遇到这样的情况，首先不能慌张，尽可能的先将线上的 BUG 解决掉，再来考虑如何在新版本中合并代码的问题，这样肯定会造成 1.1.0 的延期发布以及 1.0.1 的缺失，严重的可能还需要重新审视——但是你避免不了，不过责任是比较清楚的。

当然为了能够尽可能的避免这种情况出现，一般建议新版本上线后的一段时间内（比如一个礼拜）开发人员先暂停开发做一个休整，做做项目总结、补充一些文档之类的工作，之后再进行 1.1.0 的迭代，这样做不仅能够完美收尾，还能减少情景 2 出现的概率，对公司、开发人员以及项目管理来讲都是有利的。

分散式开发是基于分支 branches 进行开发，也是我个人比较喜欢的一种方式，其三个目录的定义如下：

trunk：稳定的主干

tag：我们认为稳定的发布包

branches：开发切片

与集中式开发不同的在于，我们 branches 中存在的是各个开发人员所负责的切片，而主干中则一直是稳定的 SNAPSHOT 版本——这其实是符合逻辑的，SNAPSHOT 代表的意义是预览而不是“破烂”，至少能够正常的运行起来才能算的上是预览版，而集中式开发的主干虽然标注的是 SNAPSHOT 预览版，实际上其实是一个“破烂”——正常情况下你是运行不起来的，开发环境总是存在各种各样的不确定性。

用语言描述一下开发步骤：在主干 trunk 中新建一个项目，然后 copy to branches，分别建立 milestone、sp1、sp2…spN，每一个切片对应一个开发或前端或白盒测试，当大家各自开发完毕之后，提交代码，项目经理将 sp1、sp2 等切片合并到 milestone 中，这里注意了，不是合并到 trunk 中，而是一个分支的名字叫 milestone——里程碑，专门用来合并各种代码，milestone 的代码进行合并之后，部署到测试环境让测试组介入测试——完毕之后合并到 trunk，然后在 trunk 上进行发布，在 tag 中归档并上线，trunk 中的版本号升级到下一版本，然后所有开发切片重新切片。

上面的描述如果感到拗口的话，可以看这个场景：

项目经理建了一个项目，版本号是 1.0.0-SNAPSHOT，程序员小王从项目经理那里领到一个任务是开发订单查询中心这个模块，他的切片是 1.0.0-SNAPSHOT-SP1，开发完毕之后提交了代码，项目经理合并代码到 milestone 上，然后小王开始开发其他的代码，项目经理陆续从小张、小李那边收到 SP2、SP3 的代码之后，觉得可以发布一版了，叫上测试对 milestone 进行测试，通过之后合并到主干打 tag 上线，此时线上版本号是 1.0.0-RELEASE，主干上的版本号是 1.1.0-SNAPSHOT，此时项目经理重新切片，所有人的代码从 1.0.0-SNAPSHOT-SPn 转换到 1.1.0-SNAPSHOT-SPn 进行开发，milestone 同样变成 1.1.0-SNAPSHOT，循环往复……

基于 SVN 的项目管理——集中与分散

同样存在集中式开发的问题——老版本出现 BUG 怎么办？我们这里同样模拟一个场景。

1.0.0-SNAPSHOT 通过了测试并且已经打 tag 上线了，线上版本是 1.0.0-RELEASE，trunk 上的版本号是 1.1.0-SNAPSHOT，milestone 上的版本也是 1.1.0-SNAPSHOT，所有的开发都已经认领了各自的 1.1.0-SNAPSHOT 的 SP 进行下一版的开发，此时 1.0.0-RELEASE 发生了一个隐藏的 BUG 需要紧急修复并上线，项目经理找到 BUG 负责人小王，让他对他所负责的 1.0.0-SNAPSHOT-SPn 进行 fix，修补完毕之后依次合并 milestone、测试、打 tag 上线，此时线上版本是 1.1.0-RELEASE，主干版本变成 1.1.1-SNAPSHOT，milestone 同样为 1.1.1-SNAPSHOT。

到此，我们产生了一个疑问：因为小王的 BUG 导致主干版本比开发的 SP 版本高了一个版本，是不是会有冲突呢？

其实是没有冲突的，SP 的版本号其实是弱化了的——实际上我根本不关心 SP 的版本号是否正确，当发生不正确的情况出现，由各个切片的开发人员自己通过 Merge 里程碑 Milestone 的代码解决。

总结一下分散式开发引申出来的几个概念：

SP：开发切片。

MILESTONE：里程碑，对应的是测试环境

TRUNK：主干，对应的是预发布环境

TAG：归档，对应的是线上环境

分散式开发重点解决的是保证测试环境的相对稳定、预发布环境的绝对稳定以及线上环境的绝对稳定问题，并且我们试想一下：是不是能够轻松做到持续交付了呢？

集中式开发适合一些小型项目的开发，例如微服务、小组件。

分散式开发适合快速迭代——对于未知的需求贴合的更好。

Ubuntu 14.04 下搭建 SVN 服务器 SVN:// http://www.linuxidc.com/Linux/2015-01/111956.htm

CentOS 6.2 SVN 搭建 (YUM 安装) http://www.linuxidc.com/Linux/2013-10/91903.htm