入门数据工程并不容易。在课堂上，甚至在网络课程中，您会掌握编写Python 和 SQL 的基础。您甚至可能会学到一些框架，以及 Airflow、Databricks 和 Snowflake 等工具。
写出能运行的代码是一回事；为代码编写测试并将其投产，使其在企业环境中运行，则是另一回事。好在软件工程已经摸索出成熟做法，而数据工程也正在逐步跟上。
您可能会问：他们是如何做到的？答案是 CI/CD。我们如何知道代码能在“野外”运行？如何确保它没有问题？在最终签署通过后，又如何将代码发布到生产环境中运行？本文将探讨数据工程中的 CI/CD。我们也有一篇关于机器学习中的 CI/CD 的独立指南。
什么是 CI/CD？
CI/CD 是“持续集成、持续交付/部署”的缩写。现在这可能对您来说还没有太大意义；我们来进一步拆解。
持续集成
持续集成是指定期将代码更改合并到中央代码库的过程。比如说，您成功修改了工程团队数据管道代码库中的一个 Python 函数。持续集成的要求是随后将这段代码合并回中央代码库。
但其中还有更多讲究。每次有变更时，都应使用某种版本控制工具（如git）对代码进行跟踪，并运行单元测试和集成测试。这带来两点好处：其一，确保代码库的最新更改可供所有其他用户使用；其二，验证代码更改确实按预期工作。
持续交付
当您将代码合并回中央代码库并完成测试后，它如何进入生产环境？这就是 CD 的用武之地。CD 指持续交付/部署（我们这里以“持续交付”为准），即以自动化方式部署对代码所做的更改。
有人可能认为单元测试和集成测试属于持续部署的一部分，但不论如何，只有经过验证的代码才会被发布到生产环境。
使用 Napkin.AI 创建
综上所述，CI/CD 是通过自动化方式，在将代码发布到生产环境（持续交付）之前，确保其可用（持续集成）的端到端过程。要实现 CI/CD，我们需要使用 CI/CD 流水线，下面将详细介绍。
数据工程中的 CI/CD
数据工程的最佳实践正越来越接近软件工程所确立的标杆。诸如开发并运行单元测试、维护专用测试/质量保证环境等任务，不再只是软件工程师的专属。这也包括 CI/CD。
在数据工程技术栈中，CI/CD 的用例俯拾皆是。以下是几个常见场景：
- 使用“Asset Bundles”打包Databricks 作业
- 将对 Airflow DAG 的更改发布到生产环境
- 为 REST API 发布新的端点，以向内部和外部数据使用者提供数据
- 更新用于准备每日报告数据的 dbt 作业
在“数据工程”的开发生命周期中引入 CI/CD，能带来诸多好处，包括对发布到生产环境的代码质量进行治理，以及减少发布变更所需的人工操作。
CI/CD 还为每次发布所涉及的步骤提供了可见性层，并可将某些操作的权限限制在特定人员范围内。
CI/CD 流水线
要执行 CI/CD，您需要使用 CI/CD 流水线。CI/CD 流水线是一系列步骤：在代码被检入中央代码库后，执行测试（CI）并将代码部署（CD）到生产环境。 下面快速看看 CI/CD 流水线可能是什么样子。
CI/CD 流水线通常包含三步：配置构建/部署环境、运行测试，以及将代码发布到生产环境。
通常，CI/CD 流水线中有三类操作。首先，需要在流水线运行的位置配置用于测试和部署代码的环境。这可能包括安装 CLI、获取密钥，最重要的是拉取最新更新的代码库。
完成环境设置后，需对将要发布的代码进行测试。这时会针对更新后的代码库运行单元测试和集成测试。通过所有测试用例后，便可将更新的代码部署到生产环境。
CI/CD 工具
在寻找运行 CI/CD 流水线的工具吗？您很幸运，可选项非常多！从开源方案到全托管服务，多种工具都能编排 CI/CD 流程。以下是几个最流行的 CI/CD 工具。
GitHub Actions
提到版本控制，您很可能会想到 GitHub。GitHub 是存放代码最流行的平台之一，因此也非常适合用来管理 CI/CD 流水线。
GitHub Actions 是一项全托管的 CI/CD 服务，允许 GitHub 用户开发、运行和管理其 CI/CD 流水线。流水线通过 YAML 文件定义，通常在某个动作（如推送至特定分支或合并拉取请求）发生时触发。使用 GitHub Actions 可带来统一的开发者体验，将版本控制与发布管理集中在同一视图中。
Jenkins
在另一端是 Jenkins。Jenkins 是开源的 CI/CD 方案，便于构建和维护自定义流水线，且常被视为 CI/CD 的行业标准。
Jenkins 具有更强的可扩展性，包括预构建插件和对分布式架构的支持。借助 Jenkins，只要您能设想出来，通常就能实现。但这种可定制性也意味着要承担相应责任，包括对 Jenkins 本身进行一定程度的运维管理。
与 GitHub Actions 不同，Jenkins 需要由用户自行托管和管理。为此，数据工程团队需要配置和管理 Jenkins 服务器、构建代理、安全访问、与版本控制客户端的集成，以及 Java 运行环境等。这意味着相当可观的运维开销，对体量较小的团队可能并不划算。
主流云服务商
对于已经上云的数据工程团队，使用云服务商提供的 CI/CD 方案通常很有吸引力。AWS 提供 CodeBuild 和 CodePipeline；Azure 支持 DevOps 和 Pipelines；GCP 提供 Cloud Build。
通常，现有云环境中的应用无需额外采购，也不要求预留支出。这些工具对习惯在云端工作的数据工程师而言直观易用，上手也很快。
CI/CD 最佳实践
在配置您自己的 CI/CD 工作流时，有一些最佳实践可以帮助体验更顺畅。首先是版本控制。
版本控制
使用版本控制跟踪代码，是构建稳健数据平台的第一步。版本控制工具（如git）不仅能跟踪代码，还能维护生产版本。版本控制客户端（如 GitHub）随后可在特定事件发生时触发 CI/CD 流水线。
示例工作流如下：您是一名数据工程师，任务是创建一个新的ETL 工作流。为此，您检出一个功能分支并在该分支上进行更改。当您准备将这些更改推送到生产环境时，您会将功能分支合并到main 分支，随后将触发 CI/CD 流水线，把您的代码部署到生产环境。
可见性
并非总能为 CI/CD 流水线增加可见性，但在可行时务必这样做。根据您使用的 CI/CD 工具，您可以将流水线中的每一步拆分为独立任务。这样一来，一旦某个任务失败，就能快速定位并开始修复。如果您使用 GitHub Actions 运行 CI/CD 流水线，尝试将环境配置、测试和部署步骤拆分为三个不同任务。
与对流水线执行过程的可见性同等重要的，是文档化。添加关于流水线如何触发、对代码库运行了哪些测试、部署目标为何等说明，有助于快速启动故障排查。
保护您的密钥
在代码通过测试后，您很可能需要使用某种密码或密钥来部署代码库。务必不要将这些敏感信息直接存储在 CI/CD 流水线配置中（这么做必然会让安全团队头疼）。相反，应利用 CI/CD 工具将这些密钥作为变量进行存储和引用。以 AWS CodeBuild 为例，可以在流水线定义之外通过环境变量存储敏感值，并在流水线中安全引用。
使用不止一个环境
到目前为止，我们只讨论了使用 CI/CD 流水线将代码推送到生产环境。然而，企业级开发流程会有所不同。数据工程师通常会先将代码推送到专用测试环境，而不是在代码有变更时直接推送到生产。
这使他们能够手动测试解决方案，确保其产生预期结果。为此，会通过版本控制同时维护test 和 main 分支，并在特定事件发生时各自触发略有差异的 CI/CD 任务。
结论
没错，CI/CD 可能较为棘手，也确实需要一些时间完成初始配置。但 CI/CD 是一项投资，旨在让代码在生产环境中的发布受治理且高效。在前期投入时间构建 CI/CD 流水线，有助于减少手动测试代码更改以及打包发布到生产所花费的时间。
理解并实施 CI/CD 是提升职业水平的捷径之一；如果您能用 Python 或 SQL 构建项目，您已具备作为数据工程师的扎实基础技能。但如果您还能构建一个 CI/CD 工作流，使其在每次变更时自动执行测试用例，并自动化推送到生产环境，就表明您已准备好构建企业级解决方案。
立即通过 DataCamp 的Python 数据工程师职业路径和数据工程师职业认证，开启成为数据工程师之路。
入门数据工程并不容易。在课堂上，甚至在网络课程中，您会掌握编写Python 和 SQL 的基础。您甚至可能会学到一些框架，以及 Airflow、Databricks 和 Snowflake 等工具。
写出能运行的代码是一回事；为代码编写测试并将其投产，使其在企业环境中运行，则是另一回事。好在软件工程已经摸索出成熟做法，而数据工程也正在逐步跟上。
您可能会问：他们是如何做到的？答案是 CI/CD。我们如何知道代码能在“野外”运行？如何确保它没有问题？在最终签署通过后，又如何将代码发布到生产环境中运行？本文将探讨数据工程中的 CI/CD。我们也有一篇关于机器学习中的 CI/CD 的独立指南。
什么是 CI/CD？
CI/CD 是“持续集成、持续交付/部署”的缩写。现在这可能对您来说还没有太大意义；我们来进一步拆解。
持续集成
持续集成是指定期将代码更改合并到中央代码库的过程。比如说，您成功修改了工程团队数据管道代码库中的一个 Python 函数。持续集成的要求是随后将这段代码合并回中央代码库。
但其中还有更多讲究。每次有变更时，都应使用某种版本控制工具（如git）对代码进行跟踪，并运行单元测试和集成测试。这带来两点好处：其一，确保代码库的最新更改可供所有其他用户使用；其二，验证代码更改确实按预期工作。
持续交付
当您将代码合并回中央代码库并完成测试后，它如何进入生产环境？这就是 CD 的用武之地。CD 指持续交付/部署（我们这里以“持续交付”为准），即以自动化方式部署对代码所做的更改。
有人可能认为单元测试和集成测试属于持续部署的一部分，但不论如何，只有经过验证的代码才会被发布到生产环境。
使用 Napkin.AI 创建
综上所述，CI/CD 是通过自动化方式，在将代码发布到生产环境（持续交付）之前，确保其可用（持续集成）的端到端过程。要实现 CI/CD，我们需要使用 CI/CD 流水线，下面将详细介绍。
数据工程中的 CI/CD
数据工程的最佳实践正越来越接近软件工程所确立的标杆。诸如开发并运行单元测试、维护专用测试/质量保证环境等任务，不再只是软件工程师的专属。这也包括 CI/CD。
在数据工程技术栈中，CI/CD 的用例俯拾皆是。以下是几个常见场景：
在“数据工程”的开发生命周期中引入 CI/CD，能带来诸多好处，包括对发布到生产环境的代码质量进行治理，以及减少发布变更所需的人工操作。
CI/CD 还为每次发布所涉及的步骤提供了可见性层，并可将某些操作的权限限制在特定人员范围内。
CI/CD 流水线
要执行 CI/CD，您需要使用 CI/CD 流水线。CI/CD 流水线是一系列步骤：在代码被检入中央代码库后，执行测试（CI）并将代码部署（CD）到生产环境。 下面快速看看 CI/CD 流水线可能是什么样子。
CI/CD 流水线通常包含三步：配置构建/部署环境、运行测试，以及将代码发布到生产环境。
通常，CI/CD 流水线中有三类操作。首先，需要在流水线运行的位置配置用于测试和部署代码的环境。这可能包括安装 CLI、获取密钥，最重要的是拉取最新更新的代码库。
完成环境设置后，需对将要发布的代码进行测试。这时会针对更新后的代码库运行单元测试和集成测试。通过所有测试用例后，便可将更新的代码部署到生产环境。
CI/CD 工具
在寻找运行 CI/CD 流水线的工具吗？您很幸运，可选项非常多！从开源方案到全托管服务，多种工具都能编排 CI/CD 流程。以下是几个最流行的 CI/CD 工具。
GitHub Actions
提到版本控制，您很可能会想到 GitHub。GitHub 是存放代码最流行的平台之一，因此也非常适合用来管理 CI/CD 流水线。
GitHub Actions 是一项全托管的 CI/CD 服务，允许 GitHub 用户开发、运行和管理其 CI/CD 流水线。流水线通过 YAML 文件定义，通常在某个动作（如推送至特定分支或合并拉取请求）发生时触发。使用 GitHub Actions 可带来统一的开发者体验，将版本控制与发布管理集中在同一视图中。
Jenkins
在另一端是 Jenkins。Jenkins 是开源的 CI/CD 方案，便于构建和维护自定义流水线，且常被视为 CI/CD 的行业标准。
Jenkins 具有更强的可扩展性，包括预构建插件和对分布式架构的支持。借助 Jenkins，只要您能设想出来，通常就能实现。但这种可定制性也意味着要承担相应责任，包括对 Jenkins 本身进行一定程度的运维管理。
与 GitHub Actions 不同，Jenkins 需要由用户自行托管和管理。为此，数据工程团队需要配置和管理 Jenkins 服务器、构建代理、安全访问、与版本控制客户端的集成，以及 Java 运行环境等。这意味着相当可观的运维开销，对体量较小的团队可能并不划算。
主流云服务商
对于已经上云的数据工程团队，使用云服务商提供的 CI/CD 方案通常很有吸引力。AWS 提供 CodeBuild 和 CodePipeline；Azure 支持 DevOps 和 Pipelines；GCP 提供 Cloud Build。
通常，现有云环境中的应用无需额外采购，也不要求预留支出。这些工具对习惯在云端工作的数据工程师而言直观易用，上手也很快。
CI/CD 最佳实践
在配置您自己的 CI/CD 工作流时，有一些最佳实践可以帮助体验更顺畅。首先是版本控制。
版本控制
使用版本控制跟踪代码，是构建稳健数据平台的第一步。版本控制工具（如git）不仅能跟踪代码，还能维护生产版本。版本控制客户端（如 GitHub）随后可在特定事件发生时触发 CI/CD 流水线。
示例工作流如下：您是一名数据工程师，任务是创建一个新的ETL 工作流。为此，您检出一个功能分支并在该分支上进行更改。当您准备将这些更改推送到生产环境时，您会将功能分支合并到main 分支，随后将触发 CI/CD 流水线，把您的代码部署到生产环境。
可见性
并非总能为 CI/CD 流水线增加可见性，但在可行时务必这样做。根据您使用的 CI/CD 工具，您可以将流水线中的每一步拆分为独立任务。这样一来，一旦某个任务失败，就能快速定位并开始修复。如果您使用 GitHub Actions 运行 CI/CD 流水线，尝试将环境配置、测试和部署步骤拆分为三个不同任务。
与对流水线执行过程的可见性同等重要的，是文档化。添加关于流水线如何触发、对代码库运行了哪些测试、部署目标为何等说明，有助于快速启动故障排查。
保护您的密钥
在代码通过测试后，您很可能需要使用某种密码或密钥来部署代码库。务必不要将这些敏感信息直接存储在 CI/CD 流水线配置中（这么做必然会让安全团队头疼）。相反，应利用 CI/CD 工具将这些密钥作为变量进行存储和引用。以 AWS CodeBuild 为例，可以在流水线定义之外通过环境变量存储敏感值，并在流水线中安全引用。
使用不止一个环境
到目前为止，我们只讨论了使用 CI/CD 流水线将代码推送到生产环境。然而，企业级开发流程会有所不同。数据工程师通常会先将代码推送到专用测试环境，而不是在代码有变更时直接推送到生产。
这使他们能够手动测试解决方案，确保其产生预期结果。为此，会通过版本控制同时维护test 和 main 分支，并在特定事件发生时各自触发略有差异的 CI/CD 任务。
结论
没错，CI/CD 可能较为棘手，也确实需要一些时间完成初始配置。但 CI/CD 是一项投资，旨在让代码在生产环境中的发布受治理且高效。在前期投入时间构建 CI/CD 流水线，有助于减少手动测试代码更改以及打包发布到生产所花费的时间。
理解并实施 CI/CD 是提升职业水平的捷径之一；如果您能用 Python 或 SQL 构建项目，您已具备作为数据工程师的扎实基础技能。但如果您还能构建一个 CI/CD 工作流，使其在每次变更时自动执行测试用例，并自动化推送到生产环境，就表明您已准备好构建企业级解决方案。
立即通过 DataCamp 的Python 数据工程师职业路径和数据工程师职业认证，开启成为数据工程师之路。