Skip to content

glossary

GitOps

An operating model where the desired state of infrastructure and applications lives in Git, and automated controllers continuously reconcile the live system to match it. Deployments and rollbacks become pull requests.

In depth

GitOps applies Git workflows to operations: every Kubernetes manifest, Helm values file, or infrastructure definition is stored declaratively in a Git repository that serves as the single source of truth. An in-cluster agent such as Argo CD or Flux continuously compares the live state of the system against the state declared in Git and automatically converges any drift, in either direction, by reapplying the declared configuration or flagging the difference. Changes are made by opening pull requests, which brings code review, audit history, and CI validation to operational changes; rollback is simply reverting a commit. This pull-based model is more secure than traditional push deployments because the cluster pulls changes itself and CI systems never need production credentials. GitOps pairs naturally with Kubernetes but the principles, declarative desired state, versioned in Git, automatically reconciled, apply to any infrastructure.

Why it matters

GitOps gives teams a complete audit trail of every production change, near-instant rollback, and protection against configuration drift. It removes the need to hand out cluster credentials to humans or CI systems, shrinking the attack surface while making deployments faster and more predictable.

Real-world example

example.txt

A platform team manages 40 microservices across three Kubernetes clusters with Argo CD watching a single config repo. To ship a new version, a developer's pipeline bumps an image tag in a pull request; once merged, Argo CD syncs the change within a minute. When a bad release causes errors, the team reverts the commit and the cluster heals itself.

Tools related to GitOps

Argo CDFluxKustomizeHelmGitHubJenkins X

Interview questions

  1. What are the core principles of GitOps?
  2. How does pull-based deployment differ from push-based, and why is it more secure?
  3. How does Argo CD detect and handle configuration drift?
  4. How would you structure Git repositories for GitOps across multiple environments?
  5. How do you manage secrets in a GitOps workflow?
  6. What happens in GitOps when someone makes a manual change with kubectl?