GitOps: Continuous Deployment via Git in Practice

Someone changed a setting directly in production. Nobody knows who. Nobody knows when. And the application that worked yesterday no longer works today.

This scenario is commonplace for teams managing their infrastructure without rigorous deployment discipline. GitOps is the systemic solution to this problem.

Its fundamental principle: Git is the sole source of truth for the state of the infrastructure and applications. Anything not in Git does not exist. Anything in Git is automatically enforced.

This guide explains the principles, tools, and best practices for implementing GitOps in production.

• 77% of organizations have adopted, to varying degrees, the principles of GitOps as a software delivery methodology (CNCF Annual Survey 2024)
• Argo is the CI/CD platform most associated with GitOps, used by 45% of respondents (CNCF Annual Survey 2024).

What is GitOps?

GitOps is an operational approach that uses Git as the single source of truth for the desired state of the infrastructure and applications. Any change to the infrastructure or configuration goes through a Git pull request, is reviewed, approved, and automatically applied by an operator who continuously synchronizes the actual state of the system with the state described in Git.

This is a natural evolution of DevOps , extending software engineering practices (versioning, code review, CI/CD) to infrastructure operations. Where DevOps brings Dev and Ops teams closer together around application deployment, GitOps automates the continuous reconciliation between what is described and what actually runs in production.

The 4 principles of OpenGitOps

The OpenGitOps project (CNCF) has formalized four fundamental principles.

• Declarative : The desired system state is described declaratively (YAML files, Helm charts, Kustomize overlays). We describe what we want, not how to achieve it.
• Versioned and immutable : the desired state is stored immutably in Git. The complete history of each change is viewable and reversible.
• Automatically retrieved : the software agents (ArgoCD, Flux) automatically retrieve the desired state from Git and apply it without human intervention.
• Continuously reconciled : agents constantly monitor the gap between the actual state and the desired state. Any drift is automatically corrected.

GitOps vs. classic CI/CD: the essential distinction

In a typical CI/CD pipeline, the pipeline "pushes" changes to the target environment (push model). A `kubectl apply` or `helm upgrade` script is executed from within the pipeline.

In GitOps, it's the opposite. An agent deployed in the cluster "pulls" changes from Git (pull model). The CI pipeline never directly interacts with the cluster. It simply updates the Git repository. The agent handles everything else.

This reversal is fundamental for security: the pipeline no longer needs to access the production cluster.

Reference tools: ArgoCD and Flux

ArgoCD: the de facto standard

ArgoCD is the most widely adopted GitOps controller in the Kubernetes ecosystem. It monitors one or more Git repositories and automatically synchronizes the cluster state with what is described in those repositories.

Its web interface is one of its distinguishing strengths. It provides real-time visualization of the status of each deployed application, the differences between the Git state and the cluster state, the deployment history, and rollback operations. Its ease of use makes it a particularly popular tool with teams new to GitOps.

ArgoCD natively supports Helm, Kustomize, Jsonnet, and raw YAML manifests. Its multi-tenancy model and RBAC integration make it the preferred solution for Kubernetes platforms shared between multiple teams.

Flow: the native GitOps alternative

Flux is the CNCF's GitOps project, co-created by Weaveworks. Its approach differs from ArgoCD: rather than a monolithic application with a central web interface, Flux is a set of specialized Kubernetes controllers (Source Controller, Kustomize Controller, Helm Controller, Notification Controller).

This architecture, based on native Kubernetes controllers, makes it more flexible and extensible than ArgoCD. It integrates seamlessly into complex GitOps workflows with advanced multi-tenancy requirements or integration with external systems.

ArgoCD vs. Flux Comparison

Setting up GitOps on Kubernetes

Git repository structure

Two main approaches structure GitOps repositories.

A monorepo centralizes all configurations in a single repository. Simple to manage for small teams, it can become difficult to govern with many teams and applications.

Multi -repo separates configurations by team, application, or functional area. While more complex to orchestrate, it offers clear isolation of responsibilities and permissions.

A universal best practice is to separate the application code repository from the GitOps configuration repository. The CI pipeline updates the configuration repository. The GitOps agent synchronizes the cluster from this repository.

Environment management

Each environment (dev, staging, prod) corresponds to a branch or dedicated directory in the GitOps repository. Promoting a version from dev to staging and then to prod is done via pull requests or automated merges between branches.

This structure ensures that production can only be modified by the defined process, never directly.

Helm and Kustomize: configuration management

Helm encapsulates Kubernetes applications in configurable charts. In a GitOps workflow, ArgoCD or Flux apply the Helm charts directly from Git, with parameters specific to each environment.

Kustomize allows you to customize basic YAML manifests with environment-specific overlays, without templating. It's native to kubectl and particularly well-suited for teams that prefer to avoid the complexity of Helm templating.

Secrets management in a GitOps workflow

Secrets should never be displayed in plain text in Git. Three approaches are commonly used.

Sealed Secrets encrypts secrets in Git with an asymmetric key. Only the controller deployed in the cluster can decrypt them.

External Secrets Operator synchronizes secrets from an external manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) to Kubernetes Secrets.

SOPS (Secrets OPerationS) encrypts secrets files with PGP, KMS or Age keys before committing them to Git.

GitOps in production: best practices

1. Strictly separate application and infrastructure repositories

Application code and deployment configuration have different lifecycles and different responsible teams. Mixing them in the same repository creates coupling and confusion.

2. Define explicit promotional strategies

Promoting between environments should be a documented and automatable process: pull request with review, automated testing on the target environment, and human approval for production. Avoid ad hoc promotions that bypass the process.

3. Monitor drift continuously

Configuration drift occurs when the actual state of the cluster deviates from the state described in Git. ArgoCD and Flux automatically detect and correct this. Configure alerts to be notified when drift persists despite reconciliation attempts.

4. Instrumenting the observability of the GitOps pipeline

Deployment metrics (frequency, synchronization time, failure rate) should be visible in your observability platform. ArgoCD natively exposes Prometheus metrics, as does Flux.

GitOps and security: RBAC and audit trail

The pull model: the fundamental safety advantage

In a typical push model, the CI/CD pipeline has write access to the production cluster. A compromised credential can trigger unauthorized changes directly in production.

In the GitOps pull model, the pipeline never has access to the cluster. It only writes to Git. The agent in the cluster retrieves and applies the changes. The attack surface is drastically reduced.

Access control in ArgoCD

ArgoCD has an RBAC system that controls who can synchronize which applications, from which repositories, and to which clusters. Permissions are defined declaratively and versioned in Git like the rest of the configuration.

Full traceability

Each deployment is tracked in Git with the pull request author, reviewer, approval date, and hash of the applied commit. In case of an incident, the audit trail is complete and unalterable. Rollback is performed with a single `git revert` or an ArgoCD operation.

Smile and GitOps: our production practice

At Smile, we have been implementing GitOps workflows in production since the emergence of the paradigm. Our practice covers ArgoCD for multi-team Kubernetes platforms, Flux for architectures requiring maximum scalability, and both in hybrid configuration for clients with very specific requirements.

We support DevOps teams and engineers starting out in GitOps with practical training geared towards real-world use cases, from junior DevOps engineers discovering ArgoCD to platform architects designing multi-cluster strategies.

Our conviction: an infrastructure without GitOps is an infrastructure whose state no one really knows at any given time.

Do you want to implement GitOps in your organization? Discover our practical approach to GitOps .

Frequently Asked Questions about GitOps

Does GitOps only work with Kubernetes?

No, but that's where it's most mature. The GitOps principles (Git as the source of truth, continuous reconciliation, pull model) apply to any infrastructure. Terraform with a GitOps backend, Ansible driven from Git, server configurations managed via Flux: GitOps can extend beyond Kubernetes. However, the ecosystem of tools (ArgoCD, Flux) is optimized for Kubernetes, and it's in this environment that it offers the best experience.

What is the difference between GitOps and CI/CD?

CI/CD covers continuous integration (testing, building) and continuous deployment (automated delivery). GitOps is a specific approach to continuous deployment that mandates the pull model and Git as the source of truth. CI/CD is possible without GitOps (a pipeline that pushes directly to the cluster). However, GitOps is not possible without CI/CD (the CI pipeline is necessary to update images and configurations in Git).

ArgoCD or Flux: how to choose?

For a team just starting out, ArgoCD is recommended thanks to its intuitive web interface that makes GitOps immediately visible and understandable. For an advanced team that wants deep integration into the Kubernetes ecosystem and maximum extensibility, Flux is preferable. Both are excellent choices, and many organizations use both depending on their use cases.

How to manage secrets in a GitOps workflow without exposing them in Git?

Three approaches are recommended depending on the context. Sealed Secrets for its simplicity and independence from external services. External Secrets Operator for organizations that already have a secrets manager (Vault, AWS Secrets Manager). SOPS for teams that prefer a lightweight solution without additional infrastructure. All three integrate natively with ArgoCD and Flux.