GitOps vs CI/CD: A Platform Team’s Decision Guide, Migration Workflow, and Checklist

Overview

CI/CD describes the broader practice of automatically building, testing, and delivering software. GitOps is a deployment operating model that treats Git as the authoritative source for the desired state of applications and infrastructure, with an agent in the target environment reconciling that state. As a result, GitOps and CI/CD can work together: a CI pipeline builds and verifies an image, while a GitOps controller deploys the approved version to Kubernetes.

The right choice depends on your environment, not on the popularity of a particular tool. Consider how many clusters you operate, whether deployments must be auditable, how teams handle secrets, how quickly rollback must occur, and whether application teams need direct access to production systems.

GitOps introduces useful controls, but it does not remove the need for CI. Tests, image creation, vulnerability checks, software bills of materials, signing, and release approvals still belong in a well-designed delivery process. Likewise, a CI/CD pipeline can use declarative manifests and pull-request approvals without adopting a full GitOps controller.

For platform engineering teams, a common target architecture is to separate responsibilities: CI produces immutable, verified artifacts; a deployment repository records which artifact should run in each environment; and a controller applies that declaration. This separation makes the platform easier to standardize while keeping application teams responsible for service-level configuration.

Checklist by scenario

Choose or retain a conventional CI/CD deployment when:

• Your targets include virtual machines, managed services, or third-party systems that are not represented cleanly as declarative resources.
• Release steps require sequential business or operational procedures that cannot yet be expressed safely as code.
• The team has a small number of environments and can maintain tightly scoped deployment credentials.
• Your immediate priority is improving build, test, or artifact quality rather than changing deployment control.
• The organization is not ready to operate a reconciliation controller, its alerting, or its access model.

Adopt GitOps for selected Kubernetes workloads when:

• Environment configuration is already stored in Git and can be reviewed, validated, and promoted through pull requests.
• You need a consistent deployment workflow across multiple clusters or teams.
• Operators need a clear record of who changed desired state and why.
• You want drift detection and a defined response when live resources differ from the repository.
• Application teams can use a platform interface without receiving broad cluster-admin access.

Use a hybrid model when:

• CI builds and tests artifacts, while GitOps manages Kubernetes deployment state.
• Some workloads are declarative but legacy systems still require pipeline-based release steps.
• Infrastructure changes need a separate approval path from application releases.
• You need a gradual migration rather than a simultaneous change across every service and cluster.

A practical CI/CD-to-GitOps migration workflow

1. Inventory the current path. Document pipeline stages, deployment credentials, manifest sources, environment-specific values, admission controls, health checks, and manual steps. Record how rollback works today before changing it.
2. Select a low-risk pilot. Choose a service with repeatable deployments, a clear owner, automated health checks, and a rollback-friendly release process. Avoid beginning with the most stateful or business-critical workload.
3. Separate build output from deployment intent. Have CI produce a versioned image or package. Do not allow the deployment repository to depend on a mutable tag such as latest. Use a digest or another immutable identifier where your tooling supports it.
4. Create the deployment repository. Store base manifests or Helm values separately from environment overlays. Keep application code and deployment configuration linked through pull requests, release metadata, or automation rather than undocumented manual edits.
5. Validate before synchronization. Run YAML, schema, policy, manifest, and security checks in CI. Render templates and inspect the resulting resources. Confirm that namespace, service account, resource limits, probes, network policy, and secret references are present.
6. Install and scope the reconciler. Whether you use Argo CD, Flux, or another controller, begin with the narrowest repository, namespace, and permissions that support the pilot. Define who can approve changes and who can change controller configuration.
7. Run a controlled synchronization. Compare the controller's planned changes with the existing pipeline result. Deploy to a non-production environment first, then verify workload readiness, logs, metrics, traces, ingress behavior, and dependent services.
8. Define rollback before production. A rollback should identify the last known-good Git revision or artifact, revert the desired state, wait for reconciliation, and verify application health. For urgent incidents, document the approved emergency path and the follow-up commit that restores repository consistency.
9. Measure and expand carefully. Track failed deployments, synchronization errors, recovery time, manual interventions, and unauthorized drift. Migrate another service only after the pilot's gaps have been addressed.

Example repository layout

platform-config/
├── apps/
│   ├── catalog/
│   │   ├── base/
│   │   │   ├── deployment.yaml
│   │   │   ├── service.yaml
│   │   │   └── kustomization.yaml
│   │   └── overlays/
│   │       ├── staging/
│   │       └── production/
│   └── checkout/
├── clusters/
│   ├── staging/
│   │   └── apps.yaml
│   └── production/
│       └── apps.yaml
├── policies/
├── project-config/
└── README.md

The exact layout can differ for Helm, Kustomize, or another configuration approach. The important properties are ownership, environment boundaries, validation rules, and a predictable path from an approved change to a deployed resource. For chart versioning and release checks, see the Helm chart maintenance guide.

What to double-check

Security and compliance

• Use separate identities for CI, the deployment controller, developers, and emergency operators. Grant only the permissions each path requires.
• Do not commit plaintext secrets. Use a deliberately selected secret-management integration and test both rotation and recovery.
• Protect deployment branches and require reviews for production changes. Treat controller configuration and access policies as production code.
• Scan dependencies and images, generate an SBOM when required by your process, and verify signatures or attestations before deployment. The Cosign image-signing workflow and SBOM guide provide related implementation considerations.
• Decide how to handle exceptions. A direct cluster change may be necessary during an incident, but it should create an alert and a documented reconciliation step.

Reliability and rollback

• Define readiness and liveness behavior before relying on automated health status. A running container is not necessarily a healthy release.
• Test rollback with realistic dependencies, database compatibility, migrations, queues, and external APIs.
• Set alerts for failed synchronization, prolonged reconciliation, unhealthy workloads, and repository-to-cluster drift.
• Keep a human-readable release record that connects the Git revision, image digest, change request, and observed outcome.

For a Kubernetes-specific review, use the Argo CD application health checklist when troubleshooting sync status and drift. Cluster changes should also follow a tested Kubernetes upgrade runbook.

Common mistakes

• Framing GitOps as a replacement for CI. GitOps controls desired state; it does not replace unit tests, integration tests, artifact creation, or supply-chain checks.
• Migrating every workload at once. A pilot reveals permission, secret, dependency, and observability problems without putting the entire platform at risk.
• Using mutable image tags. If the same tag points to different content, Git may show no configuration change while the deployed artifact changes underneath it.
• Making the repository difficult to review. Excessive templating, copied manifests, and unclear ownership make approval less meaningful. Prefer small, explainable changes and generated output that can be inspected.
• Ignoring out-of-band operations. A controller cannot make drift harmless. Decide whether it should overwrite, alert on, or permit specific changes, and document emergency access.
• Choosing tools before defining the operating model. Argo CD, Flux, Tekton, Jenkins, and related tools solve different parts of delivery. Start with the desired controls, interfaces, and responsibilities, then evaluate the tool combination.
• Automating unsafe rollback. Reverting a manifest may not reverse a database migration or an irreversible external action. Classify changes and define rollback boundaries in advance.

When to revisit

Revisit this decision before seasonal planning cycles, after a major change in cluster count or team structure, and whenever deployment failures expose a control gap. Also review it when you introduce a new compliance requirement, change cloud or Git providers, move from one cluster to many, or add stateful services that need a different release strategy.

Tool and platform updates are another trigger. Before upgrading a controller, Kubernetes version, Git provider integration, pipeline engine, Helm chart, or manifest API, test synchronization, permissions, health checks, notifications, and rollback in a non-production environment. Confirm that command examples, custom resource definitions, admission policies, and sample pipeline YAML still match the versions you operate.

Use this short review at each migration:

• Is Git still the accurate source of desired state?
• Can CI identify the exact artifact being deployed?
• Can an authorized reviewer explain and approve every production change?
• Are secrets, permissions, signatures, and policy checks working as intended?
• Can the team detect drift and restore a known-good state without guesswork?
• Have rollback and recovery been tested since the last significant workflow change?

If the answers are clear, retain the current model and improve it incrementally. If several answers are uncertain, pause expansion, document the gap, and use the next low-risk service to validate a safer design. Platform engineering works best when GitOps or CI/CD is treated as an operating contract for teams, not simply as a tool installation.