主干分支模型中的CI、CD （ 二）

分支模型

主干分支模型如上图，

项目有个主干分支和若干个release分支，还有一些临时的feature分支。

主干分支：

开发人员在主干分支上（通常情况下是master分支）push代码，push代码签需要在本地做rebase并且合并。 

如果release分支发现bug，开发人员也在主干分支上直接提交此bug的修复。

Release分支：

每一个版本发布（需要部署到生产环境或者发布给客户）会产生一个Release分支。

Release分支上发现bug后，开发人员修改bug提交到主干分支，CI通过后，Cherry pick到release分支。

Short-Lived Feature分支

每个开发者在一天（或者几天，不能超过一周），在此Feature分支上提交代码，然后通过MR，经过review后提交到主干分支。

Short-Lived Feature分支上的 CI Pipeline：

开发人员把代码push到分之后，触发此分支上的CI Pipeline，其目的主要是帮助开发人员保证代码质量，同时在合并会主分支时，给review者提供代码质量依据。

代码Push到此分之后，触发CI pipeline，包括：代码质量检查， 代码静态检查，单元测试，编译打包。

CI出错后，开发人员继续修改并提交，之后的提交会取消之前提交的pipeline执行。

在MR合并之前需要保证CI执行成功。

主干分支上的CI pipeline

push到主干分之后，触发主干分支的CI pipeline，此处的CI pipeline包括：代码质量检查， 代码静态检查，单元测试，编译打包，接口测试，集成测试，动态安全扫描等。 

CI如果失败，则通知相关的开发人员，开发人员修改后，push到主干触发新的CI pipeline。

CI如果成功， 则把编译好的二进制包打上集成标签（Snapshot-commit号），发布到二进制仓库。

在此模型中， 如果提交的非长频繁，则后面的提交的ci pipeline会取消掉前面的ci pipeline, 知道某个提交间隔有足够多的实践完成所有持续集成工作。

Release分支上的CD pipeline

需要发布前，release经理在某个CI成功的节点上创建release分支。

Release分支创建时或者以后Cherry pick后， 执行release分支上的持续部署pipeline：升级之前的二进制包为生产环境，部署到生产环境。