项目版本与分支管理之阿里AoneFlow模式分析 – zhoulin-circle

前言

在我前期的项目管理的经验中,一个项目需要维护多个产品及多个版本,这给版本与分支的管理增加了难度。前期没有重视,使得分支太多太乱,版本也没记录好,引发了很多的问题。在多种分支与版本的管理模式下,最终参考阿里的AoneBased模式来管理分支。在此做个总结并分享给大家,希望可以帮助大家找到适合自己项目的版本管理方式。

背景

碰到一个较复杂的自研项目,既要做原始功能的研发,还要做产品的定制化开发。前期的版本管理大致为:

  • 1、共一个主干分支master
  • 2、N个特性分支==N个发布分支(特性分支开发完成后,直接转测,直接转为发布分支)
  • 3、不定期的更新主干分支
    产生的主要问题有
  • 1、主干分支常常跟不上线上环境的代码
  • 2、大量的合并突冲,集成测试不友好
  • 3、版本记录混乱,功能点不明确
  • 4、某功能突然要撤回时,要手动去注销对应代码
    总之产生的问题非常多,整个项目代码管理混乱,非常不利于维护。后整理思绪,先总结一些常见的版本管理模式。

    一、TrunkBased模式

    组成

    一个主干分支 + 多个发布分支

    使用流程

    每个发布分支在特定的提交点从主干分支中拉取出来,进行线上部署和Hotfix.

    缺点

    多个团队或多个产品在同一个主干分支上并行开发时,发布的时候就是灾难了。需要频繁的集成和足够的测试覆盖。

    小结

    TrunkBased这种模试应该是比较常见的。但是其多是在主干分支上开发,虽能时该保持获取到最新的代码,但是非常不利于后期的维护。使用场景过于局限,适合版本维护比较单一,迭代周期比较长的的项目。比如公司官网,功能不复杂,大多都是维护下图片或动态,可以考虑这种版本管理模式。

    二、OneFlow模式

    此模式是TrunkBased的升级版,增加了Hotfix分支,采用多主干模式,一般是双主干(一个主干分支+一个主干发布分支)。OneFlow在TrunkBased模式演进中,做了一此改善,分离了主干分支和发布分支,有效的规避了一些问题。但是同样还不能满足多版本,多产品的并行开发。

    三、GitFlow模式

    组成

    一个主干分支+一个开发分支+N个特性分支+N个发布分支+N个Hotfix分支

    使用流程

从流程图可以看出,主干分支保持了与线上环境的代码同步,但又有主发布分支隔离了未测试的不稳定代码。每次项目有新需求时,从主干分支上拉取一个最新的特性分支进行开发。开发完成时合并到发布分支上进行集成与测试,发布成功后才合到主干分支中。

小结

可以看出,GitFlow版本管理模式比较符合多版本的并行开发。所以它非常受一些很注重流程的公司青睐。但是,看似不错的模式在实现运用中也还是会出现问题。比如大量的合并冲突,集成测试不友好等。那么在如此情况下,阿里的AoneFlow模式就很好的改善了这些问题,接下来看。

四、AoneFlow模式

组成

一个主干分支+N个特性分支+N个发布分支

使用流程


从流程图可以看出,AoneFlow模式只有一个主干分支。每次有新需求时,从当前主干分支拉取一个特性分支。多个特性分支可同步开发,到发布时间节点时,根据不同的环境合并不同的分支。如测试环境发布分支,演式环境发布分支,线上环境发布分支等。成功发布后,发布分支的代码应合并到主干分支上。同样,每次合并到主干分支时要打上tag,做好记录。最后把发布分支上关联的特性分支删除。

小结

AoneFlow模式可以看出,对于维护不同环境和不同版本的情况下非常适用,也不会产生多余的分支,主干分支与线上环境保持一致。当我们碰到有某个功能要撤销时,可以直接回滚到某次合 并记录中,去除某个发布分支,合并其余分支。利于可维护。整个流程简单有规则,轻松高效管理项目版本与分支。

总结

通过以上一系列的分析梳理,我在项目中碰到的版本管理问题得到了解决。相信大家也都能找到适合项目的管理方式。无论怎样,大小版本的记录是少不了的。想要做好一个项目的管理,让项目更好的可读可维护,我们需要做好很多细节的工作。每一个环节都寻找更优的方法。版本的管理只是其中的一部分,前路漫漫,作重而道远。欢迎各位大佬多多指点!



You must enable javascript to see captcha here!

Copyright © All Rights Reserved · Green Hope Theme by Sivan & schiy · Proudly powered by WordPress

无觅相关文章插件,快速提升流量