持续集成与持续部署(CICD)

持续集成与持续部署 (CI/CD)

它是什么？

持续集成和持续交付/部署（CI/CD）是一种开发方法论，旨在解决在集成过程中遇到的典型问题。当多名开发人员并行工作时，维护一个稳定且无错误的主分支变得越来越困难。通过CI/CD，集成过程中的步骤被自动化，并且应用程序的生命周期不断受到监控。理想情况下，这种方法可以避免“集成地狱”，即多名开发人员各自开发功能后发现无法顺利整合代码，不得不花费大量时间来审查和修复代码的情况。

参考《敏捷术语表》中对“集成地狱”的定义：

集成地狱是指交付团队成员将各自编写的代码整合到一起的生产阶段。在传统的软件开发环境中，这个整合过程通常并不顺利，可能会耗费数小时甚至数天的时间来修复代码，才能最终完成整合。持续集成（CI）的目标是完全避免这种情况，通过鼓励团队成员频繁地（例如每小时或至少每天）进行集成来实现。

持续集成

持续集成（CI）的目标是快速生成可工作的代码。成功的CI意味着应用程序的变更会定期构建、测试和合并。这种集成可能每天发生多次，并且通常涉及自动化测试用例和明确的构建流程，以尽量减少错误。使用CI方法论时，主要关注点应该是：

1. 小块代码：减少你对主分支的贡献量，而是更频繁地进行贡献。这样可以尽早发现错误并减少与其他贡献的冲突。小规模集成也意味着测试用例可以更快运行，你的代码可以更快地提供给其他可能受其影响的开发者。
2. 自动化测试：虽然存在不使用自动化测试的CI“管道”，但在实践中，自动化测试带来的好处远远超过手动测试。如果开发人员每天多次集成代码，手动测试就会变得麻烦、不一致，并且通常会浪费开发者的生产力。

持续交付

这个术语经常与持续部署互换使用，但有时会有细微差别。通常，持续交付指的是开发者如何不断地将已经经过测试的代码交付出去。这并不意味着集成后的代码会在生产环境中使用。在持续交付过程中，从开发环境到仓库的代码推送过程是自动化的，减少了或消除了手动步骤。

持续部署

尽管每个团队的做法不同，但持续部署通常指的是集成后的代码会自动部署到应用程序的生产站点。持续部署和持续交付经常都被包含在CD中，因为典型的CI/CD流水线通常同时包括这两者，它们相辅相成。

CI/CD 流水线的元素

RedHat 在他们的文章《什么是CI/CD流水线？》中提供了以下定义：

构成CI/CD流水线的步骤是任务的子集，这些子集被称为流水线阶段。典型的流水线阶段包括：

• 构建 - 应用程序在此阶段被编译。
• 测试 - 代码在此阶段进行测试。这里的自动化可以节省时间和精力。
• 发布 - 应用程序在此阶段被交付到仓库。
• 部署 - 在此阶段，代码被部署到生产环境。
• 验证和合规性检查 - 验证构建的步骤由组织的需求决定。例如，像Clair这样的镜像安全扫描工具可以通过将其与已知漏洞（CVEs）进行比较来确保镜像的质量。

声明:
本文件灏天文库团队进行了翻译。尽管我们力求准确，但请注意，翻译可能包含错误或不准确之处。原文档以其原始语言为准。我们不对因使用此翻译而产生的任何误解或误译负责。