CI/CD 简介:提升软件开发效率

65 阅读7分钟

本文介绍了持续集成 (CI) 和持续交付 (CD) 的概念、优势、流程以及在云原生和 Kubernetes 环境中的应用。CI/CD 旨在加速和自动化软件开发和部署过程,通过自动化测试、一键部署和快速发布等手段,提高软件质量和用户体验。同时,文章也提到了 CI/CD 实践中面临的挑战,如版本控制、测试和安全问题。

译自:Introduction to Continuous Integration and Continuous Delivery (CI/CD)

作者:TNS Staff

持续集成是将代码(更新或现有功能)与现有代码库(例如,软件工具或产品)合并的过程。CI 是一种开发实践,开发人员每天多次将代码合并到中央存储库中。

在 CI 中,添加到代码库的每一行代码都会触发 CI/CD 管道中的一个序列,从而为开发人员生成反馈。此过程允许快速、轻松地进行改进。

CD 试图加速和自动化部署。运维人员可以在一周内跨多个服务推送多次部署,并了解部署过程中应用程序和基础设施的确切状况。

“持续交付是持续集成的自然延伸,在这种方法中,团队确保对系统的每一次更改都是可发布的,并通过按下按钮发布任何版本。持续交付旨在使发布变得乏味,以便我们可以频繁交付并获得关于用户关心内容的快速反馈。”——Thought Works

通过持续交付,对系统所做的每一项更改都可以发布,并且可以随时发布任何版本。持续集成是持续交付的自然延伸。持续交付提供关于用户关心内容的快速反馈,并旨在使发布成为例行且可预测的事情。

持续集成和持续交付 (CI/CD) 过程正在改变 DevOps。即使软件开发生命周期的每个步骤都可以手动执行,CI/CD 也会自动执行软件开发和部署中的各个阶段。

平台工程如何帮助负责任地管理创新

CI/CD 管道的重点

为了成功运行 CI/CD 管道,组织应概述指导开发人员方法和流程的目标。虽然每个管道都是独一无二的,但它应该反映一些总体目标。

以下是一些应成为管道重点的结果:

在后续更新中快速修复和改进

CI/CD 自动化 自动允许代码更改反映在最终用户的软件中。CI/CD 管道应优先考虑对现有代码的快速修复和改进,以提高软件质量和用户体验。

一键部署

持续交付需要一个“状态”机,CI 工具不提供该机器。CD 工具(例如 Spinnaker)可以将环境从一种状态变为下一种状态,直到它进入生产环境。该机器将以自动方式将环境(例如 Docker 容器)移动到生产环境。它甚至能够执行回滚、金丝雀部署和扩展实例。

此过程允许实现理想的 CD 思维模式所驱动的敏捷、一键式、自动化部署。此类管道是 CD 功能的核心,因为它们在各个阶段协调可重复的部署。

快速且频繁的软件发布

DevOps 转型中的一个更高级别的成就是持续交付。在 CI/CD 管道中关注软件发布是公司的一种文化转变,因为它也涉及组织变革。DevOps 转型意味着建立具有共同目标的跨职能团队,围绕架构调整组织,并创建持续改进的文化。

采用 CI/CD 可以使您的 DevOps 团队受益的三个方面

有效 CI/CD 工作流程的结构

实现 CI/CD 目标的过程已被分解为不同的阶段。目标是确保新的、可运行的代码在发送给最终用户之前适合使用。

大多数独特且有效的管道都遵循以下结构:

每个新的管道运行都由源代码存储库中的更改触发。对现有代码的更新或变动(例如自动化工作流程或先前管道运行的结果)会启动 CI/CD 过程。

在此阶段,将创建可能部署给最终用户的可运行代码实例。这是通过源代码及其依赖项的组合来完成的。未通过此阶段的代码表明项目配置存在问题,应立即引起注意。

在代码上运行自动化测试 以确定其准确性。这些测试由软件开发人员创建,需要满足某些标准。此阶段的多个测试将检测开发人员无法预见的错误或其他问题。测试可能需要几分钟或几个小时,具体取决于其复杂性。未成功通过此测试阶段的代码会立即通知开发团队必须进行调整。在测试代码并认为其可运行后,将其交付到存储库。

部署。 一旦代码通过所有预定义的测试,存储库中的可运行代码就会部署到不同的环境,例如内部团队的暂存环境和最终用户的生产环境。

验证和合规性。组织需求决定了验证和合规性中发生的事情。例如,映像安全扫描工具可确保映像质量并将其与已知漏洞进行匹配。

云原生 CI/CD 工具的方法正在改变

对持续交付 (CD) 的日益关注带来了新的工具和实践,这些工具和实践使团队能够生成频繁、快速且乏味的自动化发布。云原生 CI/CD 需要更深入地了解 DevOps 实践以及它们如何影响组织使用容器、微服务和无服务器函数部署和管理工作负载的方式。

一种新的持续集成和持续交付 (CI/CD) 方法正在为云原生架构兴起。使用云原生架构,复杂性正在从代码的构建和组装转移到编排发布。Travis CI 和 Jenkins 等构建工具开始商品化并变得更加简单。

随着越来越多的组织习惯于使用容器和其他不可变构造构建自定义代码,他们在构建该代码上花费的周期越来越少,并转向解决编排发布的问题。

Kubernetes CI/CD 的影响

Kubernetes,开源容器编排器,通过工具、模块化和不可变的基础设施使 CD 更易于执行。Kubernetes 简化了微服务的部署和监控。它有助于定义容器部署和管理实例,但让用户自己将这些部署自动化到环境中。

以下是一些用于改进 Kubernetes CI/CD 的行之有效的实践:

实施蓝绿部署策略。与为紧急情况做准备类似,此策略涉及一种模式,该模式为现有实例创建一组额外的生产实例,以便在发生故障或停机时快速切换。蓝色代表暂存环境,而绿色代表生产环境。

利用基于 Git 的工作流程。CI/CD 管道应通过 GitOps 激活。这可确保管道中的更改和源代码存储在统一的源存储库中,以便于更正和部署。

测试和扫描新的容器映像。每次创建新映像时都测试和扫描容器映像可以处理漏洞,例如使用新构建引入的配置问题。它还可以确保命令正常工作。

CI/CD 框架的挑战

尽管 CI/CD 过程在不断发展,但它并非没有挑战。面临的一些困难包括:

版本控制。CI/CD 模型需要从源代码存储库创建版本以确保连续性。由于所做的更改数量,管理这些变体可能很困难。

错误的测试。编写新代码时,开发人员应编写多个测试以确定产品的准确性和行为。如果未执行正确的测试,开发人员可能会收到错误的反馈循环,这可能会完全影响最终产品。

安全漏洞。人们对开发、集成和部署阶段 CI/CD 过程的安全性提出了担忧。敦促软件开发人员在编写代码的过程中制定安全措施,而不是在周期结束时制定。

CI/CD 实践在不断完善。通过 The New Stack 文章在此类别中了解有关 CI/CD 趋势、新方法和行业专家意见的更多信息。