一、什么是CI（持续集成）？
可以帮助开发人员更加频繁地（有时甚至每天）将代码更改合并到共享分支或"主干"中。
系统会通过自动构建应用并运行不同级别的自动化测试来验证这些更改，确保这些更改没有对应用造成破坏。
1、持续：长期、频繁不断的、周期性；
2、集成：将一些孤立的事物或者元素通过某种方式联系在一起，从而构成一个有机整体的过程
1、传统的开发过程下的坑：
- BUG总是很晚才被发现，并且难以修复；
- 研发交付质量无法得到保障；
- 变更频繁，研发效率低下；
- 重复性劳动，无效等待过多，用户满意度低；
持续集成便能为我们解决这些难题。
二、持续集成的优点
1.可以提高软件开发和交付过程的透明度和洞察力：
- 人人都能看到正在发生什么，持续集成主要在于交流，自动化部署脚本便很重要了。
- 保证每人都能看到当前系统的状态和已做的修改。
2.有效减少重复过程，节省时间、成本和工作量，完全自动化，利于尽早发现问题：
- 做持续集成需要多种环境，不同的构建阶段需要不同的环境，自动化部署脚本便很重要了。
- 由于失败是时而会发生的事情，我们希望能快速回滚到失败之前的状态。我们在部署时也不用畏首畏尾
PS：自动化部署不仅可以加速部署过程，并且能够减少部署错误
3.可以帮助开发人员更加频繁地（有时甚至每天）将代码变更合并到共享分支或“主干”中；防止分支大幅偏离主干：
- 在更新本地代码库时进行构建，意味着我们既可以发现冲突，又可以发现编译冲突。既然构建是自测试的，那么运行时的冲突也可以被检测出来。
越是频繁提交，可能导致冲突的地方就越少，因而也越容易发现；频繁提交鼓励开发者以几个小时为单位来分割代码，这样便于跟踪进度。
目的：就是让产品可以快速迭代，同时还能保持高质量；即：高效率、高质量、高产出。
代码集成到主干之前，必须通过自动化测试，只要有一个测试用例失败，就不能集成
持续集成并不能消除Bug，而是让它们非常容易发现和改正
延期集成的缺点在于，很难预测集成到底要花多少时间，更糟的是，你很难了解集成的进展情况。
持续集成正好解决了这些问题。每次集成的时间都不长，任何时候你都知道自己所处的情况，软件的哪些地方在工作，哪些没有。
三、持续集成的构成
- 需要有代码托管工具支持，如：github、gitee
- 需要有专门的集成服务器来执行集成构建，目的是将整个CI过程管理起来并自动化，结果可视化
1.本地集成：Jenkins
2.云集成：CircleCI、TravisCI
- 需要有良好的反馈机制，在构建、测试等lint任务失败后，及时通知到对应人，如：邮件、短信、语音、微信等通知方式。
- 产品、开发、测试、部署、运维共同使用的敏捷研发管理系统，市场上阿里云效、腾讯的TAPD等。
四、什么是CD？
1、CD 持续交付（Continuous Delivery）：
在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中 自动将生产就绪型构建版本发布到代码存储库 。
2、 CD 持续部署（Continuous Deployment）：
持续部署可以自动将应用发布到生产环境。 意味着开发人员对应用的更改在编写后的几分钟内就能生效
五、仓库管理：
1、mono repo：
也就是单体仓库（大仓模式），它是将所有的服务全部放到一个代码库，包含了每个业务的服务代码和公共的Lib库、Tools集合，代码都放到一起，也就更好管理
mono repo 优点有：
1.易于开发者测试
2.易于标准化代码
3.易于开展Code Review
4.易于共享公共组件，避免重复造轮子
5.易于重构
2、multi repo：
和单体仓库相反，为多仓库方式（小仓模式），每个服务代码单独成库，各自为营，彼此之间，井水不犯河水，做了很好的隔离。
multi repo 优点有：
1.服务之间职责划分清晰
2.易于扩展，服务之间的解耦
3.限制clone范围，避免代码库完全泄漏
mono repo的优点恰恰是multi repo的缺点，两者之间是互斥的关系。
中小型企业，一般用的是单体仓库，大型企业往往是多仓库。
但其实也有一些大公司，用的是单体仓库，如：Google、Facebook、Salesforce
六、分支管理：
- feature分支：具体要开发的功能的分支，完成后合并到develop
- develop分支：开发的主分支，feature和release分支会基于此分支
- release分支：用于发布新版本的分支，完成后合并到develop和master
- hotfix分支：用于紧急修复已发布的产品问题的分支，完成后合并到develop和master
- master分支：与产品环境代码保持一致的分支，也就是每次发布完成之后，发布的功能分支就要合并于此，以保持master更新
持续集成往往会基于分支做逻辑，不同的分支往往代表了研发的不同阶段；合并分支的过程，其实就是一次代码集成的过程。
PS：一个好的分支策略，不仅能使研发养成良好的开发习惯，还能加大持续集成发现问题的可能性。
七、CICD工具：
CICD 集成于 CICD 工具及代码托管服务。CICD 有时也可理解为进行 CICD 的构建服务器，而提供 CICD 的服务，如以下产品，将会提供构建服务与 github/gitlab 集成在一起。
- Jenkins
- Travis CI
- GitLab CI
如果没有 CICD 基础设置，可以尝试 github 免费的 CICD 服务: github actions。
八、设计实现：
一套CI的设计与实现，往往跟一家公司的规模、发展阶段、以及所使用的技术栈紧密相关。
1、典型场景：
2、微服务场景：
3、Cloud Native场景：
九、大厂案例分析
1、饿了么：
饿了么的业务线（外卖、物流、商户、新零售、开放平台等）非常多，光AppID（应用服务标示）就多达上千（小仓模式），而这些业务往往需要快速迭代，各种CR需求也是常有的事情；可想而知，饿了么每天的持续集成任务量，得有多大，不禁让人好奇饿了么的持续集成是如何设计实现的。
饿了么的持续集成，经历了三代的发展（Eless -> ElessV2/APPOS -> AONE）；AONE是饿了么融入阿里体系后，使用的方案，集团内技术栈打通并统一是肯定的趋势。
初代则是基于Jenkins，根据每个仓库的语言类别，执行Jenkins上对应的Job任务(例如：ci-python-job/ci-java-job)，每个Job任务，会根据仓库根目录下的CI YAML完成编译构建之外的CI环节。
环境划分：
- alpha环境：开发自测环境
- beta环境：qa测试环境
- ppe/vip环境：预发环境，几乎等同于线上，仅允许办公网用户测试
- prod环境
AoneFlow只有feature、release、master三类分支。
AONE平台集成了在线解决冲突、在线Code Review、发布完毕自动合并release分支到master分支的优点，可以保证线上的包都经过了所有环境的验证。
2、哔哩哔哩：
B站的CI和研发绑定的尤为密切，整个CI过程，只要CI（各种各样的Lint检测任务）不通过，就不让合入代码。
B站的研发测试环境，主要依赖于服务节点染色的概念，和k8s甬道（给pod打标签）的方式是类似的，不过B站每个染色节点都是单独可测的，上下游请求链路完全打通，也就是说：它满足了多需求可以同时测试。
总结：
其实总的来说，也就那么两条路子，要么自研、要么使用开源版；有能力和时间的公司，往往会选择自研，毕竟开源版，很多功能都是受限的，也无法很好地融入到企业技术栈，需要深度定制；
所以你会发现，基于开源版二次开发，往往是大部分公司的路子。
最后
为大家准备了一个前端资料包。包含54本，2.57G的前端相关电子书，《前端面试宝典（附答案和解析）》，难点、重点知识视频教程（全套）。
有需要的小伙伴，可以点击下方卡片领取，无偿分享