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
