基于Git分支模型的devops实践指南

分支分类

• 1. 个人开发分支, 分支名一般叫username/feature-xxx或者username/hotfix-xxx 比如

neozhao/lauch-ci
neozhao/hotfix-v12

• 2. 团队开发分支，就叫develop，该分支不直接提交代码，一般mr合并
• 3. 发布分支，就叫release，该分支也不直接提交代码，tag只在这个分支上，一般添加tag就意味着即将发布
• 4. 归档分支，归档主分支，代码老旧稳定（只接受合并，不能推送代码）

配置管理

对想要ci的分支，需要在配置中心配置开发环境

• 目标机器/集群
• 配置文件

除了分支以外，还要配置以下三种环境的配置

• 测试环境
• 预发布环境
• 灰度发布环境
• 全量生产环境
  以上配置都是可选的，如果没有配置，执行该步部署时直接跳过

ci工作流设计

• 1. 个人开发分支提交时，必触发执行

单元测试
代码扫描
构建制品(<appname>-<branch>-<ts>-<gitrevision>.<postfix>)
推送制品
分支环境部署

• 2. 团队开发分支提交时，触发的工作流与个人开发分支完全相同，只是这一次是集成到团队的开发环境而已
• 3. 发布分支合并时，也会触发以上的工作流，但是，发布分支不应该配置环境，所以不会部署。
• 4. 开发根据自己的判断在发布分支添加tag时，会触发以下流程：

单元测试
代码扫描
构建制品(<appname>-<tag>-<ts>-<gitrevision>.<postfix>)
推送制品
测试环境部署
开发签名提测
系统集成测试
测试签名通过
触发CD工作流（可选，我的工作流可以由别人的工作流触发吗？）

cd工作流设计

输入：制品ID

1. 授权检查（开发提测签名+测试通过签名）
2. 预发布环境部署（pre确认，post检查+回滚）
3. 灰度环境部署（pre确认，post检查+回滚）
4. 全量生产环境部署（pre确认，post检查+回滚）
   以上确认都是运维权限的

注意：cd制品名称和ci的制品名称是命名方式是不一样的

注意：添加tag，分支合并，代码归档，这些操作开发手动完成即可

注意：尽量不要动环境，如果部署操作出错就修改工作流，让所有踩过的坑都沉淀在流水线里