Git voor cloudbeheerders: best practices voor versiebeheer buiten softwareontwikkeling

By Mirko Peters · 2026-08-13

Welkom terug bij de podcast en ons begeleidende blog! Als je cloudbeheerder, systeemingenieur of DevOps-professional bent en je ooit servers op afstand hebt leren beheren via remoti…

Automatically translated with AI from the original post. Read the English original

Welkom terug bij de podcast en onze bijbehorende blog! Als je cloudbeheerder, systeemingenieur of DevOps-professional bent en je ooit servers hebt beheerd door er op afstand op in te loggen en configuratiebestanden rechtstreeks aan te passen, neem dan even een diepe adem. We moeten het hebben over je mappenstructuur. Je weet wel welke ik bedoel. Het is de map op je bureaublad, of erger nog, een map op een gedeelde netwerkschijf of een productie-jumpbox, met submappen als production_config_final_v2_FINAL_fixed, nginx.conf.bak.old en main_terraform_script_DO_NOT_TOUCH_john. We hebben allemaal in die chaotische wereld van ad-hocbackups en handmatig gekopieerde bestanden geleefd.

In deze blogpost bouwen we verder op de podcastaflevering van vandaag, waarin we dieper ingaan op waarom versiebeheersystemen zoals Git niet langer alleen voor softwareontwikkelaars zijn. Als je Infrastructure-as-Code (IaC) schrijft, cloudomgevingen beheert of implementaties automatiseert, is Git je nieuwe beste vriend. Laten we bespreken hoe je van digitaal verzamelen overstapt naar professioneel, controleerbaar en samenwerkend cloudbeheer.

Waarom cloudbeheerders versiebeheer nodig hebben

Decennia lang konden softwareontwikkelaars genieten van Git, terwijl IT-beheerders en sysadmins vertrouwden op handmatige backups, rsync-scripts en hun geheugen om wijzigingen bij te houden. Maar het cloudlandschap is fundamenteel veranderd. Tegenwoordig wordt onze infrastructuur in code gedefinieerd. Of je nu Terraform, Ansible, AWS CloudFormation, Kubernetes-manifesten of Pulumi gebruikt, je cloudomgeving is een directe weerspiegeling van tekstbestanden.

Als infrastructuur code is, is het beheren ervan als gewone data een recept voor een ramp. Dit is waarom cloudbeheerders dringend versiebeheer nodig hebben:

• Het auditspoor: Wanneer een productiedatabase om 03:00 uur offline gaat, wil het management weten wat er is veranderd. Met Git voer je één commando uit om te zien wie een beveiligingsgroepregel heeft aangepast, wanneer dat is gebeurd en waarom.
• Het vangnet: Heb je ooit middenin de nacht een configuratiewijziging doorgevoerd die een load balancer heeft laten crashen, om vervolgens te beseffen dat je de oorspronkelijke instelling vergeten bent? Versiebeheer geeft je een direct tijdreismechanisme om terug te keren naar een bekende, stabiele toestand.
• Samenwerken zonder chaos: Twee ingenieurs kunnen niet tegelijkertijd hetzelfde configuratiebestand in een gedeelde map bewerken zonder dat de een het werk van de ander overschrijft. Git lost dit probleem fundamenteel op door bijdragen veilig samen te voegen.
• CI/CD-integratie: Moderne cloudworkflows vertrouwen op automatiseringspijplijnen. Git fungeert als de enige bron van waarheid die geautomatiseerde tests, beveiligingsscans en implementatiepijplijnen start zodra een wijziging is goedgekeurd.

Git-kernconcepten voor infrastructuurteams ontrafeld

Als je nieuw bent met Git, kan de terminologie intimiderend klinken voor systeembeheerders die gewend zijn aan traditionele bestandssystemen. Laten we de kernconcepten vertalen naar begrippen die zinvol zijn voor cloudbeheer.

Repositories

Denk aan een Git-repository, of "repo", als een projectmap op steroïden. Voor een cloudbeheerder kan dit één repository zijn met alle Terraform-configuraties voor een specifieke cloudomgeving, of een centrale repo voor alle Kubernetes-clustermanifesten. De repository houdt elk afzonderlijk bestand en elke map erin bij en bewaart een volledige geschiedenis van elke wijziging die ooit is gemaakt.

Commits

Een commit is een opgeslagen momentopname van je infrastructuurcode op een bepaald moment. In tegenstelling tot het simpelweg opslaan van een bestand vraagt een commit om bewuste keuzes. Je zet je wijzigingen klaar (stage) – bijvoorbeeld het aanpassen van een firewallregel en het toevoegen van een nieuwe S3-bucket – en legt ze vast met een beschrijvend bericht, zoals "Strikt CORS-beleid toevoegen aan openbare S3-bucket." Deze momentopname is blijvend, terug te vinden en heeft een uniek hash-id.

Branches

Branches zijn de ultieme oplossing voor het probleem met mapnamen als _v2_FINAL. In plaats van je hele mappenstructuur te dupliceren om een nieuwe netwerktopologie te testen, maak je een "branch" aan. Een branch is een geïsoleerde werkruimte. Je kunt experimenteren, dingen kapotmaken, nieuwe configuraties testen en uitrollen naar een staging-omgeving zonder ooit de stabiele productiecode op de main-branch aan te raken.

Infrastructure-as-Code beheren met commits en geschiedenis

Goede commits schrijven is een kunstvorm, maar voor cloudbeheerders is het ook een compliance-eis. Wanneer je cloudresources beheert, wordt je commitgeschiedenis je operationele logboek. Laten we eens kijken hoe je Git gebruikt wanneer je IaC beheert.

Stel dat je een nieuwe virtual private cloud (VPC) inricht met Terraform. Je schrijft je vpc.tf-bestand, definieert je subnets en configureert je routeringstabellen. In plaats van blindelings terraform apply uit te voeren, ziet je workflow er zo uit:

1. Pas de bestanden met de infrastructuurconfiguratie aan.
2. Voer je lokale validatietools uit (zoals terraform validate of syntaxiscontroles).
3. Voeg de specifieke bestanden die je wilt opnemen toe aan de staging area met git add.
4. Maak een duidelijke commit aan met git commit -m "Provision staging VPC and associated routing tables".
5. Push je wijzigingen naar een externe server zoals GitHub, GitLab of Bitbucket.

Door deze workflow te volgen, vertelt je commitgeschiedenis een chronologisch verhaal over de evolutie van je infrastructuur. Als er over zes maanden een audit plaatsvindt, kunnen compliance-officers elke infrastructuurwijziging terugleiden naar een specifieke commit-hash en auteur.

Branchingstrategieën voor veilige clouduitrollen

Een van de meest angstaanjagende momenten in cloudbeheer is een update rechtstreeks uitvoeren in een productieomgeving. Traditionele sysadmin-werkwijzen stimuleren vaak een "bid en deploy"-mentaliteit. Git-branchingstrategieën nemen die angst volledig weg door gestructureerde isolatie te introduceren.

Voor cloudbeheerders werkt een vereenvoudigde Git-workflow, vaak GitHub Flow of een aangepast trunk-based development-model genoemd, uitstekend:

De main-branch

De main-branch (of soms master) is de absolute bron van waarheid voor je productie-infrastructuur. De code die hier staat, moet precies weergeven wat er nu in je productieomgeving in de cloud draait. Directe wijzigingen in main moeten strikt verboden zijn.

Feature- en taakbranches

Wanneer je een wijziging wilt doorvoeren, of dat nu het toevoegen van een nieuwe databaseinstantie, het aanpassen van IAM-rollen of het opschalen van node pools is, maak je een aparte branch aan vanuit main. Je kunt die een beschrijvende naam geven, zoals feature/add-redis-cache of fix/iam-policy-least-privilege.

Je voert al je aanpassingen door, test ze grondig in een niet-productieve sandboxomgeving en commit je wijzigingen op deze branch. Omdat je los staat van main, kun je vrijuit experimenteren zonder het risico op productie-uitval.

Samenvoegen, pull requests en teamsamenwerking

Zodra je je infrastructuurwijzigingen op je featurebranch hebt getest en er zeker van bent dat ze klaar zijn voor productie, hoe krijg je ze in productie? Hier komen samenvoegen (merge) en pull requests (PR's) om de hoek kijken.

Een pull request (of merge request) is een formeel voorstel om de wijzigingen van je featurebranch terug samen te voegen met de productiebranch main. Vanuit het oogpunt van governance en kwaliteitsborging gebeurt hier de echte magie.

Peer review

Voordat een infrastructuurwijziging in productie wordt toegepast, kan een collega je pull request beoordelen. Die kan de exacte diffs van je Terraform- of Ansible-scripts regel voor regel doorlezen. Heb je per ongeluk een open ingress-regel laten staan die verkeer vanaf 0.0.0.0/0 toestaat? Je collega kan dat opvangen voordat het ook maar bij de API van de cloudprovider aankomt.

Geautomatiseerde validatie via CI/CD

Wanneer je een pull request opent, kun je je Git-hostingplatform zo instellen dat het automatisch validatiepipelines start. Je CI/CD-systeem kan bijvoorbeeld automatisch terraform plan uitvoeren en de uitvoer rechtstreeks als opmerking in je pull request plaatsen. Het team ziet dan precies welke resources worden toegevoegd, gewijzigd of verwijderd voordat er ook maar één regel code wordt goedgekeurd.

Zodra de peer review is afgerond en de geautomatiseerde tests zijn geslaagd, klik je op de knop "Merge". Je wijzigingen zijn dan veilig opgenomen in main en klaar om te worden uitgerold.

Best practices voor productieklare configuraties

Overstappen op Git voor cloudbeheer vraagt om een andere manier van denken. Om het maximale uit je versiebeheersysteem te halen, is het goed om deze best practices in gedachten te houden:

1. Commit nooit geheimen

Dit is de gouden regel van Git-beheer. API-sleutels, databasewachtwoorden, privé-SSH-sleutels en inloggegevens van cloudproviders (zoals AWS secret access keys) mogen nooit hardcoded in je configuratiebestanden staan en naar een repository worden gecommit. Als je een geheim naar een openbare repository pusht, of zelfs naar een interne repository die wordt gecompromitteerd, kunnen aanvallers het binnen enkele minuten vinden.

Gebruik in plaats daarvan omgevingsvariabelen en dienst voor geheimenbeheer (zoals AWS Secrets Manager, HashiCorp Vault of Azure Key Vault). Zorg daarnaast dat je een goed .gitignore-bestand instelt, zodat lokale statusbestanden, logbestanden en caches met inloggegevens worden genegeerd.

2. Schrijf beschrijvende commitberichten

Vermijd luie commitberichten zoals fix stuff, update of wip. Als je maanden later in het commitlogboek zoekt naar de reden waarom een autoscalingbeleid is aangepast, dan bespaart een bericht als Adjust CPU threshold scaling policy from 80% to 75% for peak traffic handling je heel wat frustratie.

3. Behandel infrastructuurdocumentatie als code

Je repository moet meer bevatten dan alleen implementatiescripts. Voeg een duidelijk README.md-bestand toe waarin de architectuur, vereisten, implementatie-instructies en contactgegevens van het team dat verantwoordelijk is voor de omgeving worden beschreven.

4. Bescherm je main-branch

Stel branchbeveiligingsregels in op je Git-platform. Zorg ervoor dat de main-branch minimaal één peer review vereist, geslaagde geautomatiseerde controles en geen force pushes toestaat. Zo voorkom je per ongeluk overschrijven en worden governancebeleidsregels automatisch afgedwongen.

Conclusie: je werkwijze voor cloudbeheer naar een hoger niveau tillen

Afstappen van chaotische mapnaamconventies, handmatige configuratiebackups en cowboy-implementaties is een van de meest impactvolle carrièrestappen die een cloudbeheerder kan zetten. Door Git te omarmen, breng je professionele softwareontwikkelingsdiscipline naar de wereld van infrastructuur en operations.

Versiebeheer geeft je de ruimte om veilig te experimenteren, moeiteloos samen te werken met je team, wijzigingen eenvoudig te controleren en fouten met vertrouwen terug te draaien. Het maakt cloudbeheer van een reactief, stressvol brandjes blussen tot een proactieve, ingenieuze discipline.

Als je het nog niet hebt gedaan, zet dan vandaag nog een testrepository op, migreer een klein configuratiescript ernaartoe, maak een branch aan en ervaar de gemoedsrust die professioneel versiebeheer biedt. Bedankt dat je naar de podcast luistert en meeleest. Abonneer je vooral op meer diepgaande verhalen over cloudinfrastructuur. Tot de volgende keer: houd je commits schoon en je pipelines groen!