分支模型




主干分支模型如上图,

项目有个主干分支和若干个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:升级之前的二进制包为生产环境,部署到生产环境。