CI/CD for MLOps: How It’s Implemented in Azure, AWS, and GCP

You often hear industry experts say that CI/CD in machine learning is “just another DevOps pipeline,” but when you encounter it in practice, you realize it’s a much more complex system that integrates not only code and infrastructure but also data and models. It’s well known that in classic DevOps, Continuous Integration refers to building and testing code, while Continuous Delivery/Deployment refers to deploying the application to production. In MLOps, however, we deploy not only code but also the model, as well as the data and the training pipeline. More specifically, CI/CD in ML includes: Code verification (training scripts, inference API); data validation; Model training; model quality assessment; model registration; deployment to staging/production; and degradation monitoring.

The table below shows how MLOps CI/CD differs from classic DevOps.

From my experience, the general CI/CD architecture for MLOps has the following structure:

Git Push ↓ CI (lint + tests + data checks) ↓ Build Docker image ↓ Train model (optional step) ↓ Evaluate model ↓ Register model ↓ Deploy to staging ↓ Manual approval (optional) ↓ Deploy to production

But there are always nuances depending on the cloud provider.

In AWS’s CI/CD implementation, about which you can find a lot of interesting information in the official documentation: https://docs.aws.amazon.com/codepipeline/

https://docs.aws.amazon.com/codebuild/

https://docs.aws.amazon.com/sagemaker/

In my experience with AWS, they typically use a combination of: GitHub Actions — AWS CodePipeline — AWS CodeBuild — Amazon SageMaker

An Example of an AWS Pipeline: GitHub Actions → build Docker image

CodePipeline → deploy model to SageMaker

In AWS, GitHub Actions are often used instead of CodePipeline because GitHub Actions are simpler, have fewer configurations that are tightly integrated with AWS services, and are easier to integrate with open-source ML tools. CodePipeline is more commonly used when everything needs to be within AWS and deep integration with IAM and VPC is required.

In CI/CD on Azure, as confirmed by the technical documentation: https://learn.microsoft.com/azure/devops/ and https://learn.microsoft.com/azure/machine-learning/, the following are most commonly used: Azure DevOps, GitHub Actions, and Azure Machine Learning.

Example of an Azure DevOps pipeline configuration:

Key features of CI/CD in Azure worth noting are that the model registry is built-in, deployment pipelines are native, and there is less glue code

From GCP’s technical documentation:

https://cloud.google.com/build/docs

https://cloud.google.com/deploy/docs

[embed]Gemini Enterprise Agent Platform | Google Cloud Documentation Build, scale, govern, and optimize autonomous agents with Gemini Enterprise Agent Platform.cloud.google.com

It is clear that Cloud Build, Cloud Deploy, and Vertex AI are used for CI/CD on Google Cloud Platform.

Cloud Build Example:

Key features of CI/CD on GCP include tight integration with the data pipeline (BigQuery, Dataflow); Vertex AI simplifies end-to-end MLOps; and, in my opinion, Cloud Build is simpler but less flexible than AWS.

Summary Comparison Table

Here are my practical recommendations for MLOps professionals, based on my own experience working with three cloud providers:

If you need freedom in choosing tools, architecture, and integrations, I would recommend AWS and GitHub Actions;

If, on the other hand, the infrastructure of the company you work for is based on Microsoft technologies, then Azure ML and Azure DevOps are the best solution;

If the project you’re working on requires intensive data processing and large-scale ML training, you should consider GCP Vertex AI and Cloud Build.

In conclusion, I’d like to summarize that CI/CD in MLOps isn’t just about automating deployments, but rather the full model lifecycle, encompassing data, training, evaluation, and monitoring.