（1）GIT协同开发流程和微服务部署

checkout

项目负责人新建release/r-20220211（同步最新master）

优点：节省资源服务器，升级平滑

自动注册Eureka

消息服务器B1

执行shell脚本

研发A/B提交升级申请

feature/r-xx功能点

register

备份A2服务

升级A1相关服务

服务1

开发B

marge

不通过

local

缓存服务器C1

消息服务器B2

应用服务器A2

push

多人协同开发/升级

hotfix/r-xxbug

负责人删除未升级分支release/r-20220211

release/r-220211

应用服务器A1

Time

release/r-20220209

服务3

适用：大版本升级，涉及服务较多，平滑过渡

部署：运维jenkin构建release/r-20220211

poll

服务2

finish - commit

升级分支release/r-220211

回滚：运维人员构建上一版本（release/r-20220110）

master

缺点：需要两套集群，回滚需要评估影响

升级A2相关服务

kill A2相关服务

orgin

kill A1升级服务

注册/配置/网关服务器D1

部署方式2：滚动发布rolling deployment（eg:release/f-20220211（日常升级））

通过

剔除Eureka已注册A2服务

测试人员：验证A/B功能点

开发A

休眠若干分钟

最新

注册/配置/网关服务器D2

适用：小版本迭代，升级模块较少

备份A1服务

完成

部署方式1：蓝绿部署Blue/Green Deployment（eg:springboot1.5-->springboot2.1）

缺点：升级较慢，回滚较慢

release/r-20220210

研发A/B代码margerelease/r-20220211

release/r-20220208

构建

Git 开发流程（适合团队人数：10人以下）：master/develop           主分支，专人维护（不需要推送），合并前一天上线的release，大家开发前都拉取远端的master  到自己本地的master  ，再合并到自己的feature分支，每天开发前要保证本地代码跟master同步。feature/hotfix        命名示例： feature/crm。自己的开发主分支（不需要推送），自己本地可以有多个feature（feature/order、feature/user等等）。release        命名示例：release/r-20220211。预上线分支，本地feature测试通过后，在feature上新建release分支（远端没有）或拉取远端已有的当天的release分支，合并自己的feature到release/r-xxxxxxxx，再推送到远端，确保该分支可以被升级或回滚        注：1)自己本地至少需要有三个分支 master/develop，release/r-xxxxxxxx，feature/xxx ，      2) 需求/bug 建议新建独立分支，并且与当前最新master同步，local分支 不需要相互marge，避免本地分支代码被污染      3) 不能直接将代码提交至release/r-xxx。该分支可能被删除

次日，负责人将升级分支合master并推送orign

剔除Eureka已注册A1服务

缓存服务器C2