Tekton 分支策略
1 什么是分支策略：
可以理解为当有一个开发团队需要对同一个项目进行协同的时候，我们如何借助于 Git 这样一个代码管理工具、或者软件协同管理工具，来实现协同效应的这么一个管理机制，这就称为所谓的分支策略。
分支也分为长期分支和短期分支。
- 短期分支：是一个临时的任务并不会长期存在，是在该项目中的一个短期的存在，比如突然有一个开发需求的时候单独创建一个短期分支，当开发需求不再需要的时候将其删除即可
- 长期分支：是一个长期任务，从项目开始到项目结束将一直存在
分支策略分为以下两种：
-
单分支：只有单个长期分支，可存在一至多个短期分支
- 多分支：有多个长期分支
1.1 单分支介绍
单分支策略简介：
- 通常也称为
Feature Branch Workflow(特性分支工作流)，其中Master Branch(主分支也就是所谓的长期分支)承载项目变更历史 -
研发人员创建短生命周期的 Feature 分支（特性短分支），完成 Feature 目标相关的研发任务
-
等 Feature 开发完成后，通过 PR （Pull Request）流程，请求将代码合并至 Master Branch（主分支）
- Pull Request 分为两步：
- 研发人员请求管理人员执行合并
- 管理人员进行审核，当审核没有问题之后再将短期分支代码拉去到 master 分支上执行合并
- PR 得到确认后，CI Pipeline 即被触发，并将短期分支合并至 master 分支上，直至最后将 master Image 推送至容器仓库上。
单分支模型相关的CI示意图
- 单分支策略适配“单流水线”模型
-
该模型下，CI Pipeline 生成的 Image 可被部署到任意环境中，包括 Production 环境
-
适用于由多个可被独立部署的微服务组成的应用场景
如上图：
从我们的项目开始 master 分支将一直存在，随后整个 master 分支上的 代码提交、代码合并、代码交付 等都会保留到 master 之上。
而我们的功能开发，比如我们需要在该项目上开发一个新功能的时候都会在这个 master 分支上拉出来一个新短期分支如上图的 Feature1、Feature2，而后基于该短期分支研发在上面开发新的功能特性，等测试完毕之后没有问题在合并至 master 分支上，而这个时候我们的短期分支就会被放弃
然后 CI Build pipeline 也只能够基于我们的 master 分支来进行建构，包括代码的回滚也是基于 master 分支上的某一个特定 Release
因此单分支中有一个以下几个特点：
单分支执行流程如下：
- 一个项目立项之后会有一条 master 的主分支
- 研发团队会基于不同的功能来创建多条不同的短期分支，并在这些短期分支上进行开发、测试、构建、等操作
- 然后当短期分支开发完毕之后执行 RP 请求，并让管理人员进行审核，如审核没有问题则将触发 CI Pipeline ，则将短期分支合并至 master 分支上，并推送到对应的 master image 仓库中
- 然后这个 image 先部署至内部的测试环境，对其做一些功能测试等操作
- 如该 image 测试没有问题则将部署至预发环境中，然后将其引入一部分真实流量测试
- 如预发环境测试没有问题就会将该 image 部署至生产环境中
- 不管什么环境这里使用的都是同一个镜像
1.2 多分支介绍
多分支策略与单分支不同的点在于，会有多条长期分支，而在这个长期分支中会有 master 以及 Develop 分支。
Develop 分支是一条长期存在且独立的开发分支，因此 master 分支将不再承载开发功能而只承载发布功能，在多分支策略中最为典型的就是 Gitflow 模型。而 Gitflow 模型通常存在两个长期分支，除了 master 还有一条 Develop 分支
多分支策略简介：
多分支策略较适用于需要多团队或（和）外部协作的大型项目的管理场景，且存在多个不同的变种，较为主流是 Gitflow 模型
Gitflow 模型介绍：
使用 Develop 分支保存项目变更历史，而使用 Master 分支承载生产发布历史
也就意味着开发人员只需在 Develop 分支上研发即可，我们要在 Develop 分支上确保测试没有问题的那些关键的需要向外发布的分支节点才需要合并到 master 分支之上，所以 master 分支仅承载生产发布历史。
虽然在多分支策略中已经有了 master、Develop 两条长期分支，但是通常我们还需要在 Gitflow 中使用另外三个非常关键的短期分支
长期分支：
- Develop 分支：
保存项目变更历史
-
Master 分支：
承载生产发布历史
短期分支：
- Feature (特性分支)：
因为即便我们有了所谓的 Develop(研发分支) ，但是在一个团队中肯定有多个研发人员，并且他们都不会基于一条 Develop 分支进行开发，而是每个开发人员会自行拉出一条短期的特性分支进行开发、测试，当测试没有问题之后每个研发人员都会将代码推送至他们自己的代码仓库中。
一旦需要承载关键变更的时候则基于 PR(Pull Request) 操作，请求管理人员将代码合并至 develop 分支上，从而让 develop 分支保存对应的关键变更。
所以 develop 分支也需要有一个专用的 CI Pipeline ，因为代码合并至 develop 分支时，PR 操作也会在 develop 分支上发生
-
Release (发布分支)：
发布操作将使用一个临时的分支来完成，该分支就是 Release (发布分支)，该分支会从最新的 Develop 分支创建一个短生命周期的 Release 分支，基于 Release 分支进行持续测试和 Bug 修复，直到满足生产标准；
满足生产标准以后我们会基于该 Release 分支启动一个 CI Pipeline，而该 CI Pipeline 是可以直接向线上进行交付，所以发布完成后，Release 分支上的所有变更都要合并至 Develop 分支和 Master 分支，因为在 release 分支中会有一些 bug 修复，而这些 bug 修复在 develop、master 分支中都需要
Gitflow 策略中，仅 Release 分支 CI 的过程才会生成的镜像并允许部署到生产环境，而 Develop 分支 CI 生成的镜像只能用于发布前测试及集成测试；显然，需要回滚时，也只能使用 Release 分支此前的 CI Pipeline 生成回滚的镜像
-
Hotfix (修复分支)：
用于修复 Bug 的 Hotfix 分支要基于 Master 分支创建。
比如在线上运行的时候发现一些重大的 BUG 或漏洞的时候，Hotfix 分支就需要从 master 分支的发布历史上拉出来一个热修复分支，并在执行完修复操作以后也需要一个 CI Pipeline ，因为我们需要重新执行构建、打包、打镜像等操作，最后通过所谓的金丝雀发布、蓝绿发布等重新部署到线上环境中。
然后等修复完成以后还要将该分支合并到 master、develop 中，因为这里的热修复是面向的 BUG 在 master、develop 两个分支中都是存在的
1.2.1 Gitflow 示意图
如上图：
- 蓝色圆点线：master (主分支)
- 灰色圆点线：hotfix (热修复分支)
- 绿色圆点线：release (发布分支)
- 黄色圆点线：develop (开发分支)
- 红色圆点线：feature (特性分支)
具体流程如下：
- 从上图可以看到分别有两条长期分支(develop、master)；开发人员则基于 develop 上的 feature(特性分支) 中执行开发操作，而在 feature(特性分支) 中由于不同的开发任务所以对应的开发周期时间也是不同的所以红色圆点线的长度也不相同，然后在测试完毕之后通过 PR 操作，如果管理员检测代码之没有问题再合并至 develop 分支上。
- 此时假如是一个重大的变更则再基于 release (发布分支)， 发布一个重大的变更操作将代码合并至 master 和 develop 分支中。并发到生产环境中
- 如果此时在生产环境中的代码有重大的 BUG 或者漏洞 ，hotfix(热修复分支) 就会从 master 分支的发布历史上拉出来一个热修复分支，从而在将修复后的代码合并至 develop 和 master 分支上
1.2.2 多分支策略模型下的CI Pipeline
所以在整个 Gitflow 模型中将会存在三条不同的 CI Pipeline：
- develop CI Pipeline：
主要是将 Feature (特性分支) 所提交的新功能代码合并至 develop 分支上，并进行完整的测试，该操作则有 develop 分支的 PR 触发
-
Release CI Pipeline：
Release 分支 CI 的过程才会生成的镜像并允许部署到生产环境，同时也会将代码合并至 master 和 develop 分支上，则会创建一个 PR 请求实现触发流水线
-
Hotfix CI Pipeline
实现热修复功能之后将代码合并交付至线上生产环境中，该操作则有 Hotfix 分支的创建一个 PR 请求并触发流水线
如上图：
有两条长期分支：master、develop
有三条短期分支：release、feature、hotfix
并且由三条不同的 CI Pipeline 实现 CI 构建三个不同的 image，很显然这三个 image 所对应的环境都是不同的：
- develop image：用于测试环境
- release image：用于 预发/生产 环境，并引入真实流量进行测试，测试之后没有问题将其部署至生产环境
- hotfix image：用于测试环境，测试完成之后没有问题则合并至 master 分支，然后部署至生产环境中