主要痛点（并行的痛）：
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