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

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

集中式开发——基于Trunk的开发

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

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也在同步进行。

这里很多人会问,如何将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的开发

分散式开发是基于分支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,循环往复……

同样存在集中式开发的问题——老版本出现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:归档,对应的是线上环境

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

总结

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

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

基于SVN的项目管理——集中与分散的更多相关文章

  1. SVN的项目管理

    基于SVN的项目管理——集中与分散   我们在此处不讨论 GIT 比 SVN 好多少,也不讨论 Maven 和 Gradle 哪个好用,基于现有的开发环境,大多数公司还是采用 SVN + Maven ...

  2. 基于web的项目管理软件Redmine

    Redmine是用Ruby开发的基于web的项目管理软件,是用ROR框架开发的一套跨平台项目管理系统,据说是源于Basecamp的ror版而来, 支持多种数据库,有不少自己独特的功能,例如提供wiki ...

  3. Mac中使用svn进行项目管理

    Mac中使用svn进行项目管理,借鉴了http://blog.csdn.net/q199109106q/article/details/8655204 下面方案多人亲測可用 转载请注明出处:http: ...

  4. 基于 svn 服务器及 cocoapods-repo-svn 插件进行组件化私有库的创建

    一.准备 组件化 随着业务需求的增长,在单工程 MVC 模式下,app 代码逐渐变得庞大,面对的高耦合的代码和复杂的功能模块,我们或许就需要进行重构了,以组件化的形式,将需要的组件以 pod 私有库的 ...

  5. 基于SpringBoot的项目管理后台

    代码地址如下:http://www.demodashi.com/demo/13943.html 一.项目简介 在使用本项目之前,需要对SpringBoot,freemaker,layui,flyway ...

  6. 在Linux上创建webrev(cont)[基于svn]

    在前文中,基于git介绍了webrev工具.实际上,webrev工具还支持hg和svn.最近的工作中不可避免地要使用svn,故在此总结一下如何基于svn在Linux上创建webrev.顺便吐个槽,没有 ...

  7. .NET作品集:基于svn 的.net 持续集成工具

    作品背景 这个.net 持续集成作品还是在2014年的时候从事.net 软件项目开发的时候做的,当时部门还用着vs2008用vb.net做项目(现在也是),项目代码极混乱,版本工具用的vss,而且用的 ...

  8. 基于gitlab的项目管理流程

    框架 背景 个人是不太愿意使用用户体验差的软件来做项目管理,行业内,要找到这么一款软件,又要符合自己的需求,着实不容易.要免费,易用性要好,要安全,要有数据统计.而程序员的世界,SVN 之后,可能没有 ...

  9. centos7基于SVN+Apache+IF.svnadmin实现SVN的web管理

    一.介绍 本文介绍的是CentOS7上搭建基于Apache.SVN Server.iF.svnadmin实现web后台可视化管理SVN. iF.SVNAdmin应用程序是Subversion授权文件基 ...

随机推荐

  1. Css中的两个重要概念:块状元素和内联元素

    一.display:block display:block就是将元素显示为块级元素,一般是其他元素的容器,可容纳内联元素和其他块状元素,块状元素排斥其他元素与其位于同一行,宽度(width)高度(he ...

  2. 广州的小伙伴福利-由微软组织的在广州SQL Server线下活动

    请按照如下格式报名.

  3. 【Win 10 应用开发】加载外部的 srt 字幕

    据说系统内置的多媒体功能支持 srt. ssa 等字幕,老周测试过几种格式的字幕均能加载. SRT 字幕是最简单的字幕结构,甚至你用记事本都能做出来,就是分为几行来写. 第一行是字幕的编号,应该是从1 ...

  4. Android数据加密之Aes加密

    前言: 项目中除了登陆,支付等接口采用rsa非对称加密,之外的采用aes对称加密,今天我们来认识一下aes加密. 其他几种加密方式: Android数据加密之Rsa加密 Android数据加密之Aes ...

  5. Handler系列之使用

    作为一个Android开发者,我们肯定熟悉并使用过Handler机制.最常用的使用场景是"在子线程更新ui",实际上我们知道上面的说话是错误的.因为Android中只有主线程才能更 ...

  6. 学习Spring——两个你熟悉的不能再熟悉的场景使用

    最近公众号受邀获取了留言和赠送模板的权限,小开心(欢迎去公众号JackieZheng围观). 我们大致的了解了Spring这个框架对于依赖注入的使用和诠释可谓是淋漓尽致.因为有了Spring的这个IO ...

  7. 野路子出身PowerShell 文件操作实用功能

    本文出处:http://www.cnblogs.com/wy123/p/6129498.html 因工作需要,处理一批文件,本想写C#来处理的,后来想想这个是PowerShell的天职,索性就网上各种 ...

  8. [原创]django+ldap实现单点登录(装饰器和缓存)

    前言 参考本系列之前的文章,我们已经搭建了ldap并且可以通过django来操作ldap了,剩下的就是下游系统的接入了,现在的应用场景,我是分了2个层次,第一层次是统一认证,保证各个系统通过ldap来 ...

  9. ChatSecure

    ChatSecure是一个免费和开源消息传递应用程序的特性 OTR加密在 XMPP. 你可以连接到现有的谷歌帐户或创建新帐户 公共XMPP服务器(包括通过 Tor),甚至 连接到您自己的服务器额外的安 ...

  10. MIS性能优化常见问题与方案(辅助项目组性能优化的总结贴)

    最近帮忙公司的几个项目组进行了不同方面的性能优化,发现几个项目都出现了一些共性的问题.这里写一篇文章,总结一下这几类问题,以及其对应的解决方案.方便其它项目组参考.   常见问题一:打开页面非常慢,有 ...