Skip to content
Back to glossary
DevOps Methodology

What is GitOps?

GitOps is an operational method where Git becomes the single source of truth for the desired state of an infrastructure. An agent continuously reconciles production with the contents of the repository.

What GitOps does

GitOps applies to operations the practices that development teams have used for fifteen years: versioning, pull requests, code review, traceability, rollback. The founding idea is that a Git repository no longer describes only application code, but also the desired state of the infrastructure: Kubernetes manifests, Helm charts, Terraform files, monitoring configuration. An automated agent (ArgoCD, Flux) reads this repository continuously and applies changes to the cluster to make production converge with the repository.

In practice, an operator no longer runs kubectl apply by hand: they open a pull request that modifies a YAML file, the PR is reviewed and merged, and the GitOps agent picks up the change within seconds and propagates it to the target environment.

Why teams adopt GitOps

Full auditability. Every production change is a signed commit, with author, date, context and review. For organisations subject to nFADP, GDPR or FINMA, it is the simplest way to demonstrate the operational traceability auditors require.

Instant rollback. A deployment that breaks production rolls back via git revert. The agent applies the return to the previous state automatically, with no script and no manual intervention. Mean Time To Recovery (MTTR) typically drops by a factor of 3 to 5 based on our field observations.

Cross-environment consistency. The same process applies to dev, staging, production and disaster recovery. Manual drifts disappear because any out-of-Git change is detected and automatically reconciled.

Faster onboarding. A new engineer reads the repository and understands the exact state of the infrastructure without having to ask colleagues. Tribal knowledge becomes documented by construction.

The four GitOps principles (CNCF)

  1. Declarative: the infrastructure is described in YAML/HCL, not imperative scripts.
  2. Versioned and immutable: Git is the single source of truth, never modified in place.
  3. Pulled automatically: an agent applies the desired state; nobody pushes manually.
  4. Continuously reconciled: any drift away from Git is corrected without human intervention.

In practice

On Hidora engagements, we typically deploy ArgoCD or Flux on the target cluster, configure a central repository per environment (sometimes a monorepo with one folder per cluster), and migrate existing deployments in two to four weeks depending on scope. The team-side learning curve is around fifteen days to master the PR + review + merge workflow applied to infrastructure.

When GitOps is not enough

Operations with a strong temporal or stateful character (database migrations, seed scripts, one-off critical jobs) are still best handled by classic CI/CD pipelines. GitOps shines for stable desired state; it does not eliminate the need for imperative tools for one-off cutovers.

Related Hidora services

  • Consulting: GitOps architecture design, ArgoCD vs Flux selection, workflow rollout.
  • Managed Services: operation of existing GitOps environments with 24/7 monitoring.
  • Kubernetes and CI/CD: technical prerequisites for a successful GitOps adoption.