The machine learning lifecycle involves various stages, such as data preparation and model deployment. Manually executing these stages is time-consuming and prone to human error. To move from a prototype to a reliable production system, automation needs to be adopted. The foundation for this automation is a set of practices from software engineering known as Continuous Integration and Continuous Delivery, often abbreviated as CI/CD.
These practices are about creating a fast, automated, and repeatable process for getting new code from a developer's machine into production. Let's break down each component.
Continuous Integration is the practice of automating the integration of code changes from multiple contributors into a single shared repository. Imagine a team of developers working on different features of the same application. In the past, they might work in isolation for weeks before merging all their changes together, a process that often resulted in complex and difficult-to-fix conflicts.
CI solves this problem by encouraging developers to merge their changes frequently, often multiple times a day. Each time a developer commits new code to the repository, an automated system kicks in. This system performs two main tasks:
If either the build or the tests fail, the CI system reports the failure. This provides immediate feedback, allowing the developer to fix the issue quickly while the change is still fresh in their mind. The main goal of CI is to detect integration problems early, resulting in a more stable codebase and faster development cycles.
The Continuous Integration cycle. A developer's code commit triggers an automated build and test process for immediate feedback.
Continuous Delivery is the logical extension of Continuous Integration. While CI ensures that the main codebase is always stable and working, Continuous Delivery automates the process of releasing that validated code to an environment.
After a code change successfully passes all the automated CI tests, it is automatically packaged into an artifact, a bundle ready for deployment. This artifact is then deployed to one or more pre-production environments, such as a "staging" or "quality assurance" (QA) environment. The outcome of Continuous Delivery is that you always have a production-ready version of your software that has passed all automated checks.
The final step of deploying to the actual production server is typically a manual, one-click action. This allows the business to decide the exact timing of a release. Continuous Delivery makes deployments a routine, low-risk event because the entire process leading up to production is automated and thoroughly tested.
The term CD can also stand for Continuous Deployment. The two are closely related but have one significant difference.
For most organizations, Continuous Delivery is the initial goal. Continuous Deployment is a more advanced practice that requires a high degree of confidence in the automated testing and monitoring systems. In this course, when we refer to CD, we will primarily mean Continuous Delivery, as it provides a solid foundation for automating releases without removing final human oversight.
The progression from Continuous Integration to release. Continuous Delivery automates everything up to a manual production deployment, while Continuous Deployment automates that final step as well.
By automating the build, test, and release stages, CI/CD pipelines allow teams to deliver value to users faster and more reliably. While these principles provide a strong foundation, machine learning introduces new complexities. An ML system is not just code; it is a combination of code, data, and a model. A simple code unit test is not enough. We must also validate data, test model performance, and track experiments. In the following sections, we will adapt these core CI/CD ideas specifically for the machine learning lifecycle and introduce a new component: Continuous Training (CT).
Was this section helpful?
© 2026 ApX Machine LearningAI Ethics & Transparency•