私有化部署git管理流程

NickJiangDev
4,442 阅读3分钟

git 分支结构

|- master               - 初始化项目保留的原始分支
|- master1.x            - v1.x主流程分支
|- master2.x            - v2.x主流程分支
|- develop              - 【即将废弃】
|- test                 - 【即将废弃】
|- uat                  - 【即将废弃】
|- ...

|- release              - 历史版本Tag目录
    |- main             - 主流程Tag
        |- 1.0.0
        |- 1.0.1
        |- 1.1.0
        |- 1.1.1
    |- vnpay            - 定制化Tag
        |- 1.1.0.0
    |- ...

|- dev                  - 环境部署目录
    |- main             - dev/test 主流程环境部署分支
        |- 1.0.0
        |- 1.0.1
        |- 1.1.0
        |- 1.1.1
    |- vnpay            - dev/test/uat 定制化环境部署分支
        |- 1.1.0.0
    |- ...

|- feature              - 功能分支目录
    |- js               - 个人功能分支
        |- main-1.1.0
        |- vnPay-1.1.1.0
    |- ...

结构解读

目前私有化部署管理分成两个部分主版本和定制版本

主版本: 厂商没有定制化需求，也愿意跟着我们的 bug fix 及功能迭代走

定制版本: 厂商有定制化的需求，主版本不再适用，不具有通用性，单独切出，脱离主版本进行版本管理

开发流程

  • 主版本开发

    1. 准备 Tag 分支：每一次主版本开发，从 master 对应 x.x 版本切release分支，收束在 release/main 结构下，版本号+1，进行开发.

    2. 开发、提测：从 release/main/x.x.x Tag 分支再细分功能分支和环境提测分支:

      • 【功能分支】：收束在 feature/结构下，由个人开发者维护功能分支
      • 【环境提测分支】：收束在 dev/main 结构下，分支用于 dev/test 环境的部署，命名规范同 release 结构一致，维护对应版本号

      注：分支提测通过后，当前的环境提测分支即为本次 Tag 最新的代码

    3. uat：

      • 由环境提测分支向release分支合并(dev/main/x.x.x -> release/main/x.x.x)
      • 再由release分支向主版本合并(release/main/x.x.x -> master/x.x)

    4. 最后，线上提供补丁包的形式输出

  • 定制版本

    1. 准备 Tag 分支：每一次定制版本开发，分为两种情况：

      • 从当前主流程迭代版本开始定制（默认）: 默认从当前从 master 对应 x.x 版本切release分支
      • 从指定主流程版本开始定制：从 relase/main 对应版本分支切出release分支

      切出的分支收束在 release/cropx 结构下，扩展版本号+1，进行开发.

    2. 开发、提测：从 release/crpox/x.x.x.x Tag 分支再细分功能分支和环境提测分支:

      • 【功能分支】：收束在 feature/结构下，由个人开发者维护功能分支
      • 【环境提测分支】：收束在 dev/cropx/x.x.x.x 结构下，分支用于 dev/test/uat 环境的部署，命名规范同 release 结构一致，维护对应版本号

      注：分支提测通过后，当前的环境提测分支即为本次 Tag 最新的代码

    3. 线上：

      • 由环境提测分支向release分支合并(dev/cropx/x.x.x.x -> release/cropx/x.x.x.x)

    4. 最后，线上提供补丁包的形式输出

  • 定制版本也希望拥有主版本的 bug fix 及功能迭代：

    通过 release/main/x.x.x 分支来找寻需要获取哪个版本的功能。

自动化部署

前置条件
  • [专有的部署服务器]
  • [专有的 git 项目]
部署流程

  1. 前端脚本需要的变量：

    • 上线分支：

      • 主版本为 master-x.x
      • 定制化版本为 release/cropx/x.x.x.x

    • 环境变量：

      • 主版本直接使用 uat 打包脚本
      • 定制化版本使用 pub 打包脚本，并支持修改线上服务器域名

  2. 由自动化部署服务器进行打包 📦

  3. 输出

Q&A

为什么需要维护一个 release 这样的一个 tag 分支？

维护 release 分支针对私有化部署有几点好处：

1.主版本： 可以以tag作为一次线上版本记录，随时切换版本，灵活使用。

2.定制化版本： 定制化版本脱离主版本控制，不能污染master环境，所以以当前的release分支作为自身的小master分支来进行版本维护，可以保证其独立性。

3.定制化版本在脱离主流程后，迭代过程中渴望获得主流程的功能模块，来源分支可以直接合并到目标分支。
avatar
文章
阅读
粉丝