CI/CD vs GitOps debate

Continuous integration and continuous delivery still build and test most software, but GitOps is increasingly handling the last step for Kubernetes by having clusters pull approved changes from Git instead of letting a pipeline push them directly. (gitops.tech) GitOps stores the desired state of an environment in Git and uses an automated reconciler to make the live cluster match that state. Flux, a Cloud Native Computing Foundation graduated project, describes the model as “push to Git and Flux does the rest.” (gitops.tech, fluxcd.io) Microsoft’s reference architecture for Flux splits the flow in two: a continuous integration pipeline builds and tests code, then a GitOps repository carries deployment templates and environment values for the pull-based rollout. The application repository triggers the pipeline, while the cluster syncs from Git afterward. (learn.microsoft.com) Machine learning teams have been separating the problem even further because they are not only shipping code. Google’s MLOps guide says machine learning operations combine continuous integration, continuous delivery, and continuous training, with automation for data collection, verification, training, deployment, and monitoring. (docs.cloud.google.com) That is why recent developer posts frame the argument less as “CI/CD versus GitOps” and more as “which control loop fits which asset.” The MLOps Principles project says the maturity of a machine learning process depends on the automation level of distinct data, model, and code pipelines. (ml-ops.org) The push model still has a place because many jobs are not long-running services waiting for a reconciler. Batch builds, one-off scripts, test generation, and failure triage are often triggered directly by a workflow runner, then exit when the task is done. (learn.microsoft.com, kiro.dev) That is where newer command-line tools are trying to fit. Kiro said on April 13, 2026 that Kiro CLI 2.0 added a headless mode that runs in continuous integration and continuous delivery pipelines, build scripts, or other automated workflows by using an API key and a `--no-interactive` flag. (kiro.dev, kiro.dev) Kiro’s documentation says headless sessions can automate code reviews, generate tests, or troubleshoot build failures without an interactive terminal. The same docs say administrators can still enforce governance rules such as model access policies, tool restrictions, and web fetch permissions in those runs. (kiro.dev) GitOps advocates argue the pull model reduces credential exposure because the cluster applies changes itself instead of handing broad production access to an external pipeline. Flux makes the same security case in its documentation, alongside audit trails through pull requests and Git history. (fluxcd.io) The result is not a clean replacement cycle where one pattern wins and the others disappear. Teams are keeping continuous integration for builds, using GitOps where declarative infrastructure can be reconciled, and adding machine learning or script-driven flows where code, data, and models move on different clocks. (learn.microsoft.com, docs.cloud.google.com, ml-ops.org)