切代码分支_前端多分支自动化部署

本文主要介绍自己在工作中总结的前端自动化部署方案，从分支管理到CI/CD，主要讲述过程和思路，不赘述细节。

主要痛点（并行的痛）：

• 1、前端各自开发、无统一构建环境
• 2、运营系统目前采用单项目管理，需要支撑多个业务的运营功能，多个业务并行开发测试(上线时间不一致)的情况难以避免
• 3、多人开发带来的代码混乱

解决办法思路：

针对核心问题多业务并行开发测试，引入多分支代码管理模型，相应支持多分支并行集成部署，同步解决无统一构建环境的问题。

主要讲述如下几大部分：

• 1、前端分支管理模型
• 2、多分支多环境的CI/CD
• 3、代码自动生成

一、前端分支管理模型

git的工作流模型有很多种，如集中式，gitflow，功能分支工作流等等，按照适合当前工作模式和场景的方式定义即可，针对我们所面临的问题，工作流如下：

说明：(如下xxx表示为任意名，不重复即可)

master： 作为pre-pro和pro环境发布所用的分支；不可直接提交代码

release/xxx：作为当前迭代版本的主分支，当前迭代开始时由owner或者master从最新的master分支切出，xxx没有固定的名字，可以根据需要自行决定；不可直接提交代码；此分支作为此迭代版本功能验证的分支；

feature/xxx：作为某个功能开发的分支，由开发者自行从对应的release/xxx分支切出，并在此开发分支上完成功能开发、连调、自测、静态代码检测、单元测试等，完成后提交merge request 到release/xxx，主要目的是隔离工开发者的开发内容，方便code review;

feature/bugxxx：功能类似feature/xxx，单独列出只是为了说明测试阶段的bug修复都是从release/xxx切分支出来改bug

release/hotfix：线上紧急bug修复分支，从最新的master分支切出，开发人员基于此分支切feature/xxx来修复bug或者直接在本分支上修复后提交，测试验证后提交merge request到master

可以看出如上的工作流模式其实是集中式和gitflow方式的合成体，以release/xxx分支作为迭代开发测试的主分支 解决了多业务并行开发测试的问题，release/xxx合并到master的时机可控，也为功能迭代上线时间的不确定性带来可以变化的空间

下面对关于本模型的可能的一些问题说说解决的方式或思路(欢迎补充、交流)：

1、同时进行的两个release/xxx分支，改动涉及相同的文件、公共模块、方法等带来的冲突

解决思路：1）有经验的开发人员鉴别到这种情况后协商调整，避免相互影响；2）后上线的release/xxx分支将已先上线的release/xxx的内容rebase回本分支，并解决冲突和回归验证

2、正常自动化流程会自动发布release/xxx分支的最新内容，可能会影响此分支正在测试的功能

解决思路：1）规定代码合并的时机，如每日下班后或者上班前由owner或者master或其他人定时合并，减少对正在测试功能的影响；2）新增专门用于测试的稳定分支，由测试人员去维护，自行决定将release/xxx分支合并到稳定分支的时机，此方式需要调整自动部署策略

3、其他，欢迎补充交流

以上分支模型是支持多业务同时开发测试的基础，需要相应的CI/CD去保证可行

TODO：各类分支模型详解

二、多分支多环境的CI/CD

常见的CI/CD方案有 1、gitlabCI/CD；2、利用jenkins自定义发布脚步；3、github CI/CD；4、各种云部署方案，如coding，gitee等

具体实现时可以采用1、编译构建、发布静态代码到目标机器；2、编译构建、打包为docker image采用docker部署等等方式；其中线上部署一般会涉及到CDN,那么相应的CI/CD流程要针对CDN的发布 做相应的调整；

以下基于gitlab CI/CD部署docker image的方式为例说明：

1、通过gitlab-ci.yml文件自定义构建流程(忽略了敏感信息和部分细节，仅用来说明过程)

stages: - test - build - ship - deploy cache: untracked: true job_release_test: stage: test tags: - frontend environment: name: TEST script: - 执行代码检测代码 only: - /^release/.*$/ job_release_build: stage: build tags: - frontend environment: name: TEST script: - 依赖安装、代码构建的命令 only: - /^release/.*$/ job_release_ship: stage: ship tags: - frontend environment: name: TEST script: - 将构建结果发送到远程docker镜像仓库 only: - /^release/.*$/ job_release_deploy: stage: deploy tags: - frontend environment: name: TEST script: - 部署启动docker only: - /^release/.*$/ job_master_build: stage: build image: 基础镜像路径 tags: - frontend environment: name: DEMO script: - 依赖安装、代码构建的命令 only: - master job_master_ship: stage: ship tags: - frontend environment: name: DEMO script: - 将构建结果发送到远程docker镜像仓库 only: - master job_master_deploy: stage: deploy tags: - frontend environment: name: DEMO script: - 部署启动docker only: - master

以上可以看出 通过各stage中only字段的定义，release/xxx分支都会被允许单独执行CI/CD，在部署阶段保证各release/xxx分支都被单独部署，且可单独访问，即完成了多分支并行开发测试的基本诉求。

这里边有很多细节需要运维的配合才能处理好，比如怎么让不同的release/xxx分支单独部署起来且可以单独域名或者路径访问？涉及到的docker image应该如何编排？如果是vue用到了history模式需要做访问路径重定向应该怎么处理？同一套代码部署到不同环境(test、demo、线上)访问的后端接口地址是不同的，怎么方便的处理？等等....... 这些问题都很细节，不同部署方案都有所不同，这里不在细讲，欢迎留言交流

三、代码自动生成

这部分篇幅较长，待更新完整文章...

参考文章：

https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md#241-%E5%B7%A5%E4%BD%9C%E6%96%B9%E5%BC%8F

https://juejin.cn/post/6844903869739171848