这个项目前后大概用了2个月的时间，是所有基建中我最满意的项目。

之前的文章也说过，这个产品是老东家的，我只是用自己的方式给实现出来，本身它很多功能我都不记得了。这个项目最核心的功能，要解决的问题，就是清晰的进行对需求/项目的管理和发布。

在深入探讨这个平台之前，先来说一下最开始的项目管理和发布流程，慢慢的是怎么演变到这个平台的，知道为什么才能更好的明白怎么做。

我把我经历的需求管理/发布分为3个阶段，

开发机问题

在开始之前，必须明确，到现在为止，我们的日常开发、测试、线上只有一套环境。这意味着 如果有多需求并行开发，如果不合并所有需求分支，代码会被反复覆盖，这也是发布问题的本质。

单分支开发/gitflow/jenkins

分支管理

最开始，业务单一需求少，做完一个需求才开始下一个需求，那所有人就 all in 一个需求，当时的规范是 gitflow，日常有 dev/main 分支

  • 先从 dev 拉一个本次需求的分支，比如 feat/xx，

  • 每个人再基于 feat/xx 切自己的个人分支 feat/xx-name

  • 功能开发完成，feat/xx 合入到 dev

  • 提测，从 dev 切 beta

  • 上线， beta 合入到 main 发布，main 合回到 dev

部署流程

  • jenkins 部署对应环境的 dev/test

问题

这种模式运作了小半年，存在的问题：

  • 分支太多，且都是手动管理

    • 日常开发，个人分支 合 feat

    • 部署分支，feat 合 dev -> dev 切 beta -> beta 合 mai -> main 合回 dev，整个开发非常繁琐

  • 需求功能集中在 dev/beta，如果存在某个需求临时不能上线，怎么从 dev/beta 去掉？

  • 缺少需求管理，即需求文档、负责人、分支、MR、上线记录没有关联，没有文档记录，无法追溯

这个模式给我的最大的感受就是分支太多，每天分支都是合来合去，冲突也多，代码也容易丢。

多分支并行开发/Aoneflow

分支管理

产品初见成效，业务功能越来越多，需求开始并行。我开始研究阿里的 Aoneflow，它的核心理念是基于需求进行分支管理，平台会自动合并所有需求分支到 release，发现挺合适的就切换到它了。现在的工作流是

  • 每个需求从 main 切对应的需求分支，比如 story/xxx

  • 开发者基于 story 切自己的开发分支，提交 MR 到 story

  • 登录 flow 平台，手动选择要合并的需求分支，发布即可；

  • 临时下线某个需求，在 flow 平台，手动删除即可，

  • 多个需求上线，发布 release 即可

部署流程

  • flow 平台自动化管理

问题

这种模式同样运作了小半年，可以算是很完美的方案了，但是还有点问题

  • flow 只关心部署，无法和业务迭代关联起来

    • 没有分支部署保护，允许添加个人分支部署（有些同学因为没有合并权限，经常先添加自己的开发分支去 flow 部署），无法感知分支功能，严重影响分支维护

    • 已上线的分支不会自己去掉，需要手动删除

  • 当时 gitlab 上会有很多 release 分支，提 MR 的时候，很难找到需求分支

  • 无法感知需求的上线时间，是否 delay，也没有日报管理等

  • flow 的流水线是按环境区分，不是按业务项目划分，即 dev 下有其他我并没有参与的项目，不是很直接同时也不是很安全

  • flow 登录有时效，经常几天就要重新登录

我的想法是

  • 对于开发来说，是不需要感知 flow 界面的，开发更关注部署结果；

  • 一个需求的从开始到上线要可追溯，包括

    • 当时的需求、UI、技术文档

    • 当时的开发者、分支MR

    • 部署、上线记录

成套的阿里云产品是包括这些的，但是我们没有购买。。。。

自建平台管理

这时候，我就想到了以前公司的产品，但是时间有点长，我都记不清具体有啥了，只能模糊的还原一个大概。

其实最开始我没想实现这个平台，后来业务越来越多，而且今年上半年我也想做点基建，就决定尝试一下，没想到一做就是2个月。

这里简单罗列一下功能，具体的技术方案下篇文章再细说

  • 项目管理（新建、编辑、删除）

  • 迭代管理（新建、编辑、删除）

  • 部署（开发、测试、线上）

  • 日报管理（新增、编辑、发送到群里）

  • 分支管理（根据内部规范，分类管理分支，比如 hotfix/story/release/…)

  • MR 管理 （创建MR、查看MR列表）

  • 上线记录（上线/tag记录）

PS：相比较于用了什么新技术，或许可以反向思考一下，不用新技术会有什么不好嘛。技术是服务于业务/解决问题的，脱离了上下文单纯论技术是无意义的，能真正解决问题的技术才是有用的技术。