GitOps bygger på att använda de verktyg och processer som utvecklare redan känner igen - t.ex. Git, pull requests, versionering och kodgranskning - och utvidga dem så att infrastruktur och distributionsflöden blir versionshanterade och automatiserade. Det handlar alltså inte bara om applikationskod, utan även om hur systemet ska se ut, driftsättas och underhållas.

I praktiken innebär GitOps att du har ett Git-repo som deklarerar det önskade tillståndet för din infrastruktur och/eller applikation (t.ex. Kubernetes-manifester, Helm-charts, Terraform-filer), och att en automatiserad mekanism kontinuerligt ser till att det verkliga tillståndet matchar detta deklarerade tillstånd. Genom att ändra repo och trigga en merge/pull request initieras hela kedjan från granskning till automatiserad driftsättning.
Detta ger många fördelar: spårbarhet (alla ändringar går via Git), återställning (rollback är ofta en revert i Git), större konsistens mellan miljöer och bättre samarbete mellan dev/ops-team.

Men - som med alla nya arbetssätt kräver GitOps också disciplin och rätt verktyg. Eftersom man flyttar mycket av infrastrukturen in i versionerad kod och automatisering, måste man tänka på hur man hanterar hemligheter, hur man löser skillnader mellan miljöer (dev/staging/prod), och hur man undviker att processerna blir för tungrodda. Sammanfattningsvis: Om du vill göra infrastrukturen förändringsbar med kod, versionerad, automatiskt driftsatt och synlig för hela teamet - då är GitOps en mycket intressant metod att utforska.