K8S-与CICD的融合

K8S与CICD的融合

CICD

CICD的概念

工厂里的装配线以快速、自动化、可重复的方式从原材料生产出消费品。同样，软件交付管道以快速、自动化和可重复的方式从源代码生成发布版本。如何完成这项工作的总体设计称为“持续交付”（CD）。启动装配线的过程称为“持续集成”（CI）。确保质量的过程称为“持续测试”，将最终产品提供给用户的过程称为“持续部署（CD）”。一些专家让这一切简单、顺畅、高效地运行，这些人被称为运维开发DevOps践行者。

“持续”是什么

“持续”用于描述遵循我在此提到的许多不同流程实践。这并不意味着“一直在运行”，而是“随时可运行”。在软件开发领域，它还包括几个核心概念/最佳实践。这些是：

• 频繁发布：持续实践背后的目标是能够频繁地交付高质量的软件。此处的交付频率是可变的，可由开发团队或公司定义。对于某些产品，一季度、一个月、一周或一天交付一次可能已经足够频繁了。对于另一些来说，一天可能需要多次交付也是可行的。所谓持续也有“偶尔、按需”的方面。最终目标是相同的：在可重复、可靠的过程中为最终用户提供高质量的软件更新。通常，这可以通过很少甚至无需用户的交互或掌握的知识来完成（想想设备更新）。

• 自动化流程：实现此频率的关键是用自动化流程来处理软件生产中的方方面面。这包括构建、测试、分析、版本控制，以及在某些情况下的部署。

• 可重复：如果我们使用的自动化流程在给定相同输入的情况下始终具有相同的行为，则这个过程应该是可重复的。也就是说，如果我们把某个历史版本的代码作为输入，我们应该得到对应相同的可交付产出。这也假设我们有相同版本的外部依赖项（即我们不创建该版本代码使用的其它交付物）。理想情况下，这也意味着可以对管道中的流程进行版本控制和重建（请参阅稍后的 DevOps 讨论）。

• 快速迭代：“快速”在这里是个相对术语，但无论软件更新/发布的频率如何，预期的持续过程都会以高效的方式将源代码转换为交付物。自动化负责大部分工作，但自动化处理的过程可能仍然很慢。例如，对于每天需要多次发布候选版更新的产品来说，一轮集成测试integrated testing下来耗时就要大半天可能就太慢了。

持续集成（CI-Continuous Integration）

CI 中，开发人员将会频繁地向主干提交代码，这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证；

持续集成 CI 是在源代码变更后自动检测、拉取、构建和进行单元测试的过程，持续集成的目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用；CI 的流程执行和理论实践让我们可以确定新代码和原有代码能否正确地集成在一起。

[

](https://blog.csdn.net/tojohnonly/article/details/103249881)

持续交付（CD-Continuous Delivery）

完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库；为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道，持续交付的目标是拥有一个可随时部署到生产环境的代码库。

在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化；在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中或发布给最终使用的用户。

1. 代码提交

2. 单元测试

3. 集成代码

4. 测试（Test）：这里不仅仅是单元测试，还可能包含功能测试、集成测试、系统测试等

5. 先部署到预发环境（预生产环境，Staging）：测试人员在预发环境进行产品的主流程验证，验证通过再执行下一步

6. 手动部署到生产环境（Production）：开发手动部署

持续部署（CD-Continuous Deployment）

对于一个成熟的 CI/CD 管道来说，最后的阶段是持续部署；作为持续交付（自动将生产就绪型构建版本发布到代码存储库）的延伸，持续部署可以自动将应用发布到生产环境；

持续交付意味着所有的变更都可以被部署到生产环境中，持续部署意味着所有的变更都会被自动部署到生产环境中，但是出于业务考虑可以选择不部署；如果要实施持续部署，必须先实施持续交付；

持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署；持续交付表示的是一种能力，而持续部署表示的则一种方式。持续部署是持续交付的最高阶段

DvOps

一个软件从零开始到最终交付，大概包括以下几个阶段：规划、编码、构建、测试、发布、部署和维护。

瀑布模型

瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段。

瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：

（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。

（3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

敏捷开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。

其实简单来说，就是把大项目变成小项目，把大时间点变成小时间点，然后这样：

虽然敏捷开发大幅提升了软件开发的效率和版本更新的速度，但是它的效果仅限于开发环节。研发们发现，运维那边，依旧是铁板一块，成为了新的瓶颈。

DevOps

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进