理想的CI/CD，结合gitflow

gitflow分支模型

gitflow分支介绍

• master：归档主分支，代码老旧稳定（只接受合并，不能推送代码）
• develop：开发分支（只接受合并，不能推送代码）
• release：发行分支，只有满足各种质量要求才能发行
• feature：功能分支, 常规开发分支
• hotfix：急救分支，紧急修复bug，生命周期更短

开发模式

feature分支作为个人的常规开发分支，可以理解为开发者个人的自由空间。
hotfix分支短小而临时，其他的方面与feature分支一致。
feature分支和hotfix分支推送的时候不应该触发CI，最多运行一下单元测试
feature或hotfix分支合并到develop分支不应该手动合并。
发起mr(feature或hotfix-->develop)时，先运行feature或hotfix的单元测试，达标（所有用例成功，覆盖率达到%x）后合并，合并后再次运行单元测试，如果没有问题，完成合并并将将测试报告发给参与项目的所有人；如果合并后检查有问题，拒绝mr并通知发起mr的人。
develop分支作为一个稳定的分支，保证随时可以发布到测试环境的状态

持续集成(Continuous Integration)

开发将自己工作的成果合并到develop分支，由个人可见到team可见，触发CI。只有develop分支变更时才需要触发CI。持续集成包括：

• 1.运行单元测试
• 2.质量门禁检查
• 3.集成到develop分支
  效果：集成后develop分支还是一个稳定的可发布到测试环境的状态

持续交付(Continuous Delivery)

develop分支合并到release分支，在release分支打标签并推送，触发测试和检查，通过后构建制品，持续交付包括：

• 1.运行单元测试
• 2.质量门禁检查
• 3.构建制品并推送到制品仓库
  效果：成功构建制品

什么是制品？：从原材料生成的东西叫制品，经过其他手续包装到市场发售叫产品。对我们而言，从源代码打包构建的就叫制品，开发和测试签名过的就叫产品。上线只能使用产品，就像上市只能使用产品一样

持续部署(Continuous Deployment)

制品构建成功后，进入可部署阶段：

• step1: 开发人员部署—>开发环境
  开发人员一键将制品部署到开发环境，自测没问题给制品签名，通知测试
• step2: 测试人员部署—>测试环境
  测试人员一键将开发已签名的制品部署到测试环境，测试没问题给该制品签名，制品成为产品，通知运维等待发布；有问题通知开发
• step3: 运维人员部署—>预发布环境
  运维人员一键将开发和测试已签名的产品发布到预发布环境，没问题继续，有问题回滚并通知开发和测试。
• step4: 运维人员部署—>生产环境
  运维人员一键将开发和测试已签名的产品发布到生产环境，没问题完成，有问题回滚并通知开发和测试

结束

部署完成以后，本次迭代结束，开发发起mr将release分支合并到master分支归档。然后可选删除release分支

问题：

• 1. 开发怎么将自己的开发分支部署到一台开发机器上进行开发测试？
• 2. 为什么要问第一个问题？：有些功能由于网络隔离，个人开发机上难以调试！个人开发环境与容器环境有本质不同。