DevOps的核心概念之一是CI/CD--持续集成和持续交付或持续部署，现在正在向机器学习运营（MLOps）迈进。CI/CD作为DevOps的核心实践，通过简化应用程序的构建、测试和部署到生产中，拥抱工具和方法，可靠地交付软件应用程序。让我们在下面定义这些概念。
- 持续集成（CI）
是指每次用版本控制提交并推送到代码库（构建应用程序）时，自动构建和测试代码的做法。
- 持续交付（CD）
是将每次构建部署到类似生产环境的做法，并在部署前对应用程序进行自动集成和测试。
- 持续部署（CD）
通过自动配置和部署应用程序到生产环境，用额外的步骤来补充持续集成。
持续集成VS持续交付VS持续部署持续集成VS持续交付VS持续部署|源码
过去几年开发的大多数CI/CD工具都是专门为传统的软件应用程序而设计的。正如你（可能）知道的那样，开发和部署传统的软件应用程序与构建和部署机器学习（ML）应用程序在许多方面有很大的不同。那么问题来了。
- ML团队如何采用现有的CI/CD工具来适应他们的机器学习用例？
- 是否有更好的选择，专门为ML应用而设计的？
在这篇文章中，你将了解到4个不同的团队如何使用或已经使用CI/CD概念、工具和技术来构建和部署他们的机器学习应用。本文的目的是让你从这些团队实施的不同解决方案中，对CI/CD的使用有一个广阔的视角，包括他们的用例。
使用Azure DevOps进行机器学习（ML）的持续集成和交付（CI/CD）
在本节中，我们将介绍一个团队的工作流程，该团队在Azure DevOps中为其机器学习工作负载协调了CI/CD流程。他们的机器学习工作负载主要在Azure云上运行。
这个团队帮助一个零售客户使用机器学习以自动化的方式解决票据。当用户提出票据或由维护问题产生的票据时，机器学习被用来将票据分为不同的类别，帮助更快地解决票据。
为了实现从开发到生产周期的自动化，该团队利用Azure DevOps管道设置了构建和发布任务。构建管道从候选的源代码和模型序列化（主要是使用ONNX）后，生成模型工件。
使用发布管线将工件部署到基础设施目标。发布管道在开发环境中测试后，将工件转移到质量保证（或QA）阶段。
模型测试发生在QA阶段，团队对模型服务进行A/B测试和压力测试，以确保模型可以部署到生产环境。
人工验证者，通常是产品所有者，确保模型通过测试，得到验证，然后批准使用发布管道将模型部署到生产环境。
在将模型部署到生产环境后，该团队设置了cron作业（作为其CI/CD管道的一部分），每周监测模型指标的数据漂移和概念漂移，以便在发生不可接受的漂移需要重新训练模型时，可以触发管道。
他们还通过检查Azure DevOps Pipelines中的管道发布来监控生产中的CI/CD管道的性能。检查的目的是为了确保他们的CI/CD管道是健康的，处于稳健的状态。他们检查CI/CD管道，保持其健康和稳健，所遵循的准则包括。
- 定期审计系统日志和事件。
- 集成自动化验收测试。
- 要求对管道进行修改的拉动请求。
- 在每个故事或功能被添加到管道之前，对它们进行同行代码审查。
- 定期报告对团队所有成员可见的指标。
总而言之，Azure DevOps为团队提供了一套有用的工具，使这个项目的开发（机器学习；模型构建）和运营团队能够和谐地工作。
参考资料
使用Jenkins和Argo工作流程的GitOps的ML持续集成和交付（CI/CD）
为了实现CI/CD，团队利用GitOps，使用Jenkins在测试环境中运行代码质量检查和类似生产的烟雾测试。该团队有单一的模型代码管道，每个拉动请求都要经过代码审查和自动单元测试。
拉动请求也要经过自动化的烟雾测试，他们在那里训练模型并进行预测，在一些小块的真实数据上运行整个端到端的管道，以确保管道的每个阶段都能达到预期的效果，没有任何问题。
对于模型的持续交付，在训练完每个模型后，会生成一份模型质量报告，并由领域专家通过手动流程进行审查，在得到领域专家的验证并通过所有事先的检查后，最终手动部署。
GitOps在一些常见的DevOps原则、实践和工具的基础上，采用了以Git为中心的方法。在GitOps中，存储在存储库中的代码和配置被认为是真理的源泉，基础设施会适应代码的变化。GitOps帮助他们在亚马逊EKS上以团队所需的速度交付管道，而没有操作问题。
为了保持代码质量的一致性，他们把所有的代码检查都移到了包含模型代码的Docker容器中，所以代码质量检查工具的版本和配置包括flake8、black、mypy、pytest都是统一的。这也有助于他们将本地的开发设置与Jenkins上使用的统一起来。
Docker确保他们不再有不同版本的依赖关系的问题，这可能导致本地和Jenkins或生产中的不同结果。
对于本地开发，他们有一个Makefile来构建Docker镜像，并在代码上运行所有的检查和测试。
对于代码审查，他们设置了Jenkins，它作为CI管道的一部分运行同样的检查。
该团队需要在不同的场景下对不同客户的多个数据集进行测试他们的模型。正如Tymoteusz Wolodzko在他的解释博文中所承认的，这不是他们想要手动设置和运行的东西。
他们需要协调和自动化管道，他们应该能够很容易地插入到生产环境中。Docker化他们的ML代码，使他们可以很容易地在不同的环境中移动应用程序，这包括生产环境。
对于协调，该团队从Airflow切换到Argo工作流，所以插入他们的容器只是写几行YAML代码的问题。
Argo Workflows & Pipelines是一个开源的容器原生工作流引擎，用于协调Kubernetes上的并行作业。它是一个为Kubernetes从头设计的云原生解决方案。你可以定义管道工作流程，其中单个步骤是作为一个容器进行的。
Argo工作流程使该团队能够在他们的亚马逊EKS集群上轻松运行机器学习或数据处理的计算密集型工作。管道中的模型会根据预定的作业定期重新训练，也会进行必要的测试和检查。但在模型部署之前，它们会被一个领域专家审查和审核。一旦专家确认该模型可以部署，模型就会被手动部署。
使用AWS CodePipeline和Step Functions的ML持续集成和交付（CI/CD）。
为了协调他们的CI/CD工作流程，本节中的团队使用了AWS CodePipeline和AWS Step Functions的组合，以确保他们正在构建一个自动化的MLOps管道。
感谢Phil Basford接受我的采访，介绍他的团队如何为一个公共ML用例做CI/CD。
对于这个用例，团队来自一家咨询和专业服务公司，他们在一个公共项目上工作。具体来说，他们建立了机器学习应用，解决了以下问题。
- 预测运送一个包裹需要多长时间。
- 预测一个位置，基于非结构化的地址数据，并将其解析为一个坐标系（纬度/经度）。
核心CI/CD工具
- AWS CodeBuild - 一个完全管理的持续集成服务，可以编译源代码，运行测试，并产生可以部署的软件包。
- AWS CodePipeline - 一个完全管理的持续交付服务，可以帮助你实现发布管道的自动化。
- AWS Step Functions - 一个无服务器的功能协调器，可以轻松地对AWS Lambda功能和多个AWS服务进行排序。
AWS云提供了受管理的CI/CD工作流程工具，如AWS CodePipeline和AWS Step Functions，为其机器学习项目进行持续集成和持续交付。对于持续集成，该团队使用git向AWS CodeCommit提交，从而触发CodePipeline中的构建步骤（通过AWS CodeBuild作业），而AWS Step Functions处理来自CodePipeline的每个动作的工作流程协调。
来自AWS Step Functions的工作流协调过程使该团队能够轻松管理因使用CodePipelines运行多个模型和管道而产生的复杂性。团队所做的多模型部署更容易管理和更新，因为CodePipeline中的每个管道工作都专注于一个流程，构建也更容易交付和排除故障。
下面是一个项目的例子，该项目使用AWS CodePipeline以及Step Functions来协调需要自定义容器的ML管道。在这里，CodePipeline调用Step Functions，并将容器图像URI和独特的容器图像标签作为参数传递给Step Functions。
使用AWS服务构建CI/CD管线以部署自定义机器学习模型的架构使用AWS服务构建CI/CD管线以部署自定义机器学习模型的架构
虽然这个团队选择使用这些工具来管理和协调，但值得注意的是，对于持续集成和持续交付（CI/CD）管道，AWS发布了Amazon SageMaker Pipelines，这是一个易于使用、专门为ML设计的CI/CD服务。
Pipelines是一个原生的工作流协调工具，用于构建ML管道，利用SageMaker的直接集成。你可以在这篇博文中了解更多关于使用 Amazon SageMaker Pipelines 构建、自动化、管理和扩展 ML 工作流的信息。
使用Vertex AI和TFX在谷歌云上进行ML的持续集成和交付（CI/CD）
在本节中，我们将看看一个团队在选择和使用其工作流协调和管理工具时，能够利用机器学习项目比传统软件工程项目更原生的管道。
本节将利用Hannes Hapke（Digits Financial, Inc.的ML工程师）在Google Cloud的Applied ML在线峰会期间举办的 "利用有限的DevOps资源进行快速迭代 "研讨会。
Digits Financial, Inc.是一家金融科技公司，为初创企业和小型企业提供可视化的、由机器学习驱动的费用监控仪表板。他们的用例集中在以下方面。
为现代企业创建最强大的财务引擎，能够摄取并将公司的财务信息转化为实时的业务模型。
- 从非结构化文件中提取信息，为客户预测未来事件。
- 对信息进行分类，以浮现出对客户的业务最重要的内容。
Digits的团队能够通过管理Vertex AI Pipelines产品和TensorFlow Extended来协调和管理他们的机器学习管道的持续集成、交付和部署，所有这些都在谷歌云基础设施上运行。
与传统的CI/CD工具相比，使用ML原生管道工具有助于团队确保模型质量的一致性，并确保模型在一个统一的管道中通过特征工程、模型评分、模型分析、模型验证和模型监控等标准工作流程。
通过Tensorflow Extended，该团队能够将其机器学习堆栈的每个组件视为单独的步骤，当管道部署到测试环境或生产环境时，可以由第三方工具（如Apache Beam、Apache Airflow或Kubeflow Pipelines）进行协调。他们还能够创建自定义组件并将其添加到他们的管道中，这在使用传统的CI/CD工具时是很难做到的。
与此同时，他们还将他们的ML管道从Kubeflow转移到Google Cloud的Vertex AI Pipeline，帮助他们轻松地将模型开发（ML）和操作（Ops）结合起来，形成高性能和可重复的步骤。
该团队提供的使用Vertex AI Pipelines的核心优势之一是，它帮助他们从管理他们的管道（自我托管的Kubeflow管道）过渡到利用管理的Vertex AI Pipeline服务进行工作流程协调，从而摆脱了维护存储元数据的数据库、启动集群以托管和操作构建服务器和管道的需要。
Vertex AI是一个可管理的ML平台，供每个从业者加快实验速度，加速机器学习模型的部署。它通过以无服务器的方式协调他们的ML工作流程，并使用顶点ML元数据存储他们的工作流程的工件，帮助团队实现自动化，监控和管理他们的ML系统。
过将其ML工作流程的工件存储在Vertex ML Metadata中，他们可以分析其工作流程的工件的脉络 - 例如，ML模型的脉络可能包括训练数据、超参数和团队用于创建模型的代码。
该团队的工作流程包括用TensorFlow Extended准备和执行他们的机器学习管道，并将它们运送到Vertex AI。然后，他们可以从Vertex AI管道中管理和协调他们的管道，而不需要操作他们自己的集群。
该团队能够从使用ML管道来协调和管理他们的ML工作负载中受益，有几种方式。正如Hannes Hapke在这段视频中所描述的，这家初创公司能够获得以下好处。
- 使用ML管道减少了对团队的DevOps要求。
- 迁移到管理的ML管道，减少了他们在基础设施上托管管道时运行24/7集群的费用。
- 由于ML管道是ML工作流程的本机，模型的更新很容易集成，并且是自动化的，从而使团队腾出时间专注于其他项目。
- 模型更新在所有ML项目中都是一致的，因为团队可以运行相同的测试并重复使用整个管道或管道的组成部分。
- 所有与机器学习相关的元数据和信息都有一个一站式的场所。
- 模型现在可以自动被跟踪和审计了。
可能是有用的
结论
本文揭示的一个有趣的观点是，使用CI/CD工具并不足以成功运营你的机器学习工作负载。虽然本文中的大多数团队仍然使用传统的CI/CD工具，但我们开始看到ML原生管道工具的出现，可以帮助团队（无论其规模如何）更快、更可靠地交付更好的机器学习产品。
如果你和你的团队正在考虑为你的机器学习工作负载采用CI/CD解决方案，任何一个ML原生管道工具都可能比传统的基于软件工程的CI/CD工具更值得开始使用，当然，这取决于你的团队的情况和有利的工具或供应商的合作。
