布景

跟着技能团队的发展壮大，交流壁垒越来越高，整个协作过程中存在较多的流程痛点；一起为了饯别DevOps理念，我们前端研制团队也进行了流程提效实践，本次首要共享我们对分支办理的标准的了解，旨在为大家供给愈加高效和灵敏的研制环境。

现状与痛点

前史：

  1. 向ops团队请求创立Feature分支。
  2. 向ops团队请求上线，合并代码分支等等，ops团队担任发布，对服务运转状况并不清楚。

研制的声音：

“运维忙起来发版得排队等半天，影响我们上线”

“周末/深夜紧急上线需要把运维同学叫起来，联系不上/不及时的话还会影响事务”

“master分支合并对研制来说黑盒，不确定上线完成后什么时候会合并到master”

….

运维的声音：

“便是个客服机器人，干的都是体力活”

“配置改成这样是什么含义并不清楚”

“累啊….”

….

带来的问题：

  • 版别发布危险的添加

    线上发版依赖于运维团队执行上线方案，可能会呈现忙时发版排队、配置错配或漏配的情况，这会添加发布呈现问题的危险，一起也会影响产品上线的速度和质量。

  • 毛病排查时职责不明

    当呈现线上毛病时，研制团队和运维团队可能会呈现职责不明、交流不畅的情况。这会导致毛病排查时刻过长，影响产品的可用性和用户体验。

  • 运维效能无法提升

    重复性作业将会占有运维绝大部分时刻，无法专心在运维效能的提升上。

方针

饯别Devops理念，研制运维一体化

一体化意思是将系统开发和IT运维两个过程结合起来，使得研制团队能够自己担任部署、维护和监控自己开发的应用程序。

这种模式的优点是能够加速需求的交给速度、进步运维效率和减少交流成本。

运维能愈加专心在运维效能的提升上，将效果正向反馈给研制团队。

分支管理流程分享

研制TEAM对交给质量担任

一个研制Team/Squad会包括产品、测验、前后端研制等首要角色，作为软件交给的职责单元，作为一个全体，需要对交给的软件产品的质量担任。

运维专心于运维效能提升

  1. 自动化运维工具和流程
  2. 监控体系的优化
  3. 容器化技能

具体内容

全体流程变动点，“单点->并发”的改变。

Before After
分支办理 由运维分配分支，运维合并分支，有问题再找研制 权限下沉，事务线Team闭环办理，依据团队成熟度、事务复杂度选择适宜的分支办理模型。
上线发版 收到上线请求，运维全保管，上线完成后事务线Team走验收流程 事务线Team闭环办理，发版权限放权给各TeamLeader。

环境办理

  • DEV

    • 开发环境，支撑与跨团队服务联调

  • TEST-X

    • 测验环境，多版别测验使用，版别相对安稳。(研制别动、研制别动、研制别动)

  • PREPROD

    • 回归环境、验收环境(研制别动、研制别动、研制别动)

  • PROD

    • 出产环境，面向实际用户

    分支管理流程分享

分支办理

分支办理由过去的运维全保管的方法变成松散自在的办理方法，现在不再做强制性约束，以研制团队为首要决议计划单元，将分支办理的事务下沉到研制单元内部决议计划，运维人员不再参与分支办理事宜，能更好的将重心放在运维效能的提升上。

常用分支办理模型

  • TBD(Trunk-Based-Development)
  • Git-Flow
  • Github-Flow
  • Gitlab-Flow
  • Aone-Flow
  • …

“分支办理没有银弹”

“适合团队的，才是最好的。”

GitFlow

分支管理流程分享

  • master分支

    • 只存放前史发布(release)版别的源代码。各个版别通过tag来标记。

  • develop分支

    • 用来整合各个feature分支。开发中的版别的源代码存放在这里。

  • Feature分支

    • feature分支派生自develop分支，当feature开发结束后，要合并回develop分支。feature分支永久不会和master分支打交道。

  • Release分支

    • release分支不是一个放正式发布产品的分支，你能够将它理解为“待发布”分支。我们用这个分支干一切和发布有关的工作，比方：提测、修正bug等

  • Hotfix分支

    • hotfix分支派生自master分支，仅仅用于修正bug，当bug修正结束后，立刻回归到master分支，然后发布一个新版别，比方v0.1.1。
    • 一起hotfix也要合并回develop分支。

团队Flow

团队过去的分支办理模型便是类似Aone-Flow的分支办理模型。基本兼顾了TrunkBased的“易于持续集成”和GitFlow的“易于办理需求”特色，一起躲避掉GitFlow的那些繁文缛节。

三种类型：

  • 骨干Master
  • 功能/特性Feature
  • 发布Release

创立Feature/Hotfix分支

分支管理流程分享

合并Feature分支，形成发布分支

分支管理流程分享

上线成功后，将发布分支合并回骨干

分支管理流程分享

注意的点：

  1. 上线成功后一定要将发布内容合并回骨干，坚持骨干具有最新运转版别的分支。
  2. 预发或许其他环境验收前，需要将骨干合并回功能feature分支，将代码冲突等处理前置。