Git deployment: automatisch je website deployen met versiebeheer
Handmatig bestanden uploaden via FTP is een werkwijze uit een ander tijdperk. Het is traag, foutgevoelig en biedt geen versiebeheer. Git deployment moderniseert dit proces: je pusht je code en wijzigingen gaan automatisch live. In deze uitgebreide gids leg ik uit hoe je Git deployment opzet en optimaal benut.
Waarom overstappen van FTP naar Git deployment
De traditionele workflow voor veel developers en website eigenaren is simpel maar problematisch. Je bewerkt bestanden lokaal, opent een FTP client, navigeert naar de juiste map op de server, upload de gewijzigde bestanden en hoopt dat alles werkt. Deze workflow heeft fundamentele problemen.
Het is makkelijk om bestanden te vergeten. Je wijzigt vijf bestanden, upload er vier en vraagt je af waarom de site niet werkt. Het is ook makkelijk om de verkeerde versie te uploaden. Je test lokaal, vergeet op te slaan, upload een oude versie en ziet de wijzigingen niet. Er is geen geschiedenis van wat je wanneer hebt gewijzigd. Als iets kapot gaat, kun je niet makkelijk terug naar een werkende versie.
Git deployment lost al deze problemen op. Git houdt bij welke bestanden zijn gewijzigd, dus je mist niets. Elke wijziging is een commit met een beschrijving, zodat je precies weet wat je wanneer hebt gedaan. De volledige geschiedenis is beschikbaar om naar terug te gaan indien nodig. En het deployment proces is consistent en herhaalbaar.
De verschillende benaderingen van Git deployment
Git push naar een server remote
De meest directe methode is het configureren van een Git remote op je productie server. Je pusht naar deze remote en een hook zorgt ervoor dat de wijzigingen worden toegepast op je website directory. Dit vereist SSH toegang tot je server en enige configuratie, maar is daarna simpel in gebruik.
CI/CD pipelines
Continuous Integration en Continuous Deployment pipelines bieden meer controle en flexibiliteit. Platforms zoals GitHub Actions, GitLab CI of Bitbucket Pipelines detecteren wanneer je code pusht naar je repository. Ze draaien dan een gedefinieerde serie stappen: tests uitvoeren, assets builden, en uiteindelijk deployen naar je server.
Deze aanpak is krachtiger dan een simpele git push. Je kunt automatisch tests draaien voordat code live gaat. Je kunt build stappen toevoegen voor frontend assets. Je kunt deployen naar meerdere omgevingen. Maar het vereist meer opzet en kennis van CI/CD concepten.
Hosting met ingebouwde Git integratie
Sommige hosting providers bouwen Git deployment direct in hun platform. Je koppelt je GitHub of GitLab repository en elke push naar een specifieke branch triggert automatisch deployment. Cloudways, Kinsta, Vercel en Netlify zijn voorbeelden. Dit is de makkelijkste optie als je hosting het ondersteunt.
Deployment tools
Tools zoals Deployer voor PHP, Capistrano voor Ruby, of Envoy voor Laravel bieden geavanceerde deployment functionaliteit. Je definieert deployment taken in configuratiebestanden en de tool voert ze uit. Dit is waardevol voor complexe deployments met meerdere stappen, maar overkill voor simpele sites.
Git deployment op een VPS opzetten stap voor stap
Stap een: Git installeren op de server
Log in op je server via SSH. Installeer Git als het nog niet aanwezig is. Op Ubuntu of Debian doe je dit met apt update gevolgd door apt install git. Op CentOS of RHEL gebruik je yum install git. Verifieer de installatie met git version.
Stap twee: een bare repository aanmaken
Maak een directory aan voor je Git repository, bijvoorbeeld /var/repo/mysite.git. Navigeer naar deze directory en initialiseer een bare repository met git init bare. Een bare repository bevat alleen Git data, geen working directory met bestanden. Het is puur voor het ontvangen van pushes.
Stap drie: de post-receive hook configureren
De magie zit in de post-receive hook. Dit is een script dat Git uitvoert na het ontvangen van een push. Maak het bestand hooks/post-receive in je bare repository. Dit script moet de code uitchecken naar je website directory.
Een basis script definieert variabelen voor je target directory en repository locatie. Het leest de ontvangen referenties en checkt of het de juiste branch is. Zo ja, dan checkt het de code uit naar de target directory. Maak het script uitvoerbaar met chmod plus x.
Stap vier: de remote toevoegen aan je lokale repository
In je lokale project voeg je een nieuwe remote toe die naar je server wijst. Gebruik git remote add production met het SSH adres van je repository. Je kunt de remote een naam naar keuze geven; production is beschrijvend voor waar de code naartoe gaat.
Stap vijf: deployen
Nu kun je deployen met een simpel commando: git push production main. Git pusht je commits naar de server, de post-receive hook draait, en je code verschijnt in de website directory. Elke volgende push werkt dezelfde manier.
Deployment met GitHub Actions automatiseren
GitHub Actions biedt een krachtige manier om deployment te automatiseren. Je maakt een workflow bestand in je repository onder .github/workflows. Dit YAML bestand definieert wanneer de workflow draait en welke stappen worden uitgevoerd.
Een basis deployment workflow triggert op pushes naar de main branch. De job draait op een Ubuntu runner, checkt de code uit, en verbindt via SSH met je server om een git pull uit te voeren. Je configureert de SSH credentials als secrets in je GitHub repository settings zodat ze veilig zijn.
Het voordeel van GitHub Actions boven directe git push is dat je extra stappen kunt toevoegen. Draai eerst tests om zeker te zijn dat de code werkt. Build frontend assets met npm of webpack. Stuur een notificatie naar Slack wanneer deployment slaagt of faalt. De mogelijkheden zijn uitgebreid.
Best practices voor veilige en betrouwbare Git deployment
Houd credentials buiten je repository
Dit is cruciaal en niet-onderhandelbaar. Wachtwoorden, API keys, database credentials en andere secrets horen niet in je Git repository. Zelfs als je repository privé is, is dit een risico. Gebruik environment variables die op de server zijn geconfigureerd, of een secrets manager. Voeg gevoelige bestanden toe aan je .gitignore.
Test voordat je deployt
Met CI/CD kun je automatisch tests draaien voordat code live gaat. Als tests falen, gaat de deployment niet door. Dit vangt bugs voordat ze productie bereiken. Zelfs zonder geautomatiseerde tests is het verstandig om lokaal te testen voordat je pusht.
Gebruik een staging omgeving
Deploy niet direct naar productie. Heb een staging omgeving die zo veel mogelijk lijkt op productie. Deploy eerst daar, test handmatig of geautomatiseerd, en deploy dan pas naar productie. Dit voegt een veiligheidslaag toe.
Atomic deployments overwegen
Geavanceerde deployment setups deployen naar een nieuwe directory en switchen dan een symlink naar de nieuwe versie. Als iets misgaat, kun je direct terug naar de vorige versie door de symlink terug te zetten. De oude versie blijft intact. Tools zoals Deployer ondersteunen dit patroon.
Een rollback strategie hebben
Weet hoe je terug kunt naar een vorige versie als iets misgaat. Met Git is dit technisch simpel: je kunt een commit reverten of resetten naar een eerdere staat. Maar oefen dit voordat je het in een crisis nodig hebt. Ken de commando's en weet hoe ze werken.
Specifieke overwegingen voor WordPress en Git
WordPress vraagt extra aandacht bij Git deployment. Het wp-config.php bestand bevat database credentials en hoort niet in je repository. Voeg het toe aan .gitignore en beheer het apart op de server. De uploads directory bevat door gebruikers geüploade media en hoort ook niet in Git. Gebruik .gitignore en beheer media apart of via een CDN.
De database zelf bevat content en instellingen die niet via Git gaan. Database migraties zijn complexer dan bestandsdeployment. Overweeg een tool als WP Migrate of een workflow met database exports.
Bedrock is een moderne WordPress stack die beter samenwerkt met Git. Het structureert WordPress als een dependency en scheidt configuratie van code. Als je serieus bent over WordPress met Git, is Bedrock het onderzoeken waard.
Veelgemaakte fouten en hoe je ze vermijdt
Een veelgemaakte fout is deployen zonder te testen. Het werkt lokaal dus het werkt vast in productie, toch? Nee. Omgevingsverschillen, missing dependencies en configuratieverschillen kunnen problemen veroorzaken. Test altijd.
Credentials committen is een andere fout met serieuze consequenties. Zelfs als je het later verwijdert, blijft het in de Git geschiedenis. Gebruik git-secrets of vergelijkbare tools om per ongeluk committen van secrets te voorkomen.
Geen monitoring na deployment is ook risicovol. Je deployt en neemt aan dat alles werkt. Maar check daadwerkelijk of de site draait en of kritieke functies werken. Automatiseer dit waar mogelijk.
Git deployment transformeert hoe je websites beheert. De initiële setup kost tijd, maar de voordelen in snelheid, betrouwbaarheid en traceerbaarheid maken het meer dan waard. Begin simpel met een basic git push setup en breid uit naar CI/CD wanneer je behoeften groeien.
Git deployment checklist en best practices
Een succesvolle git deployment vereist een gestructureerde aanpak. Gebruik onderstaande checklist om ervoor te zorgen dat elke git deployment soepel verloopt.
- Controleer dat alle wijzigingen gecommit zijn voor de git deployment
- Draai tests lokaal voordat je een git deployment start
- Gebruik feature branches en merge pas na review naar main
- Configureer automatische git deployment via CI/CD pipelines
- Houd een rollback-strategie klaar bij elke git deployment
- Documenteer elke git deployment in een changelog
| Git deployment methode | Complexiteit | Geschikt voor |
|---|---|---|
| Handmatige git pull | Laag | Kleine projecten |
| Git hooks (post-receive) | Middel | Enkele server |
| CI/CD (GitHub Actions) | Middel-Hoog | Teams en professionele projecten |
| Kubernetes + GitOps | Hoog | Enterprise en microservices |
Of je nu een eenvoudige website host op een VPS of een complexe applicatie beheert, git deployment maakt het beheer van je code overzichtelijk en betrouwbaar. Combineer git deployment met een goede hosting omgeving voor de beste resultaten.
Git deployment: CI/CD-pipelines opzetten
De volgende stap na handmatige git deployment is het opzetten van een geautomatiseerde CI/CD-pipeline (Continuous Integration/Continuous Deployment). Hiermee wordt je code automatisch getest en gedeployed zodra je wijzigingen naar je repository pusht.
GitHub Actions voor deployment
GitHub Actions is een populaire keuze voor geautomatiseerde deployment. Je definieert workflows in YAML-bestanden die bij elke push worden uitgevoerd. Een typische deployment-workflow bevat de volgende stappen:
- Code ophalen uit de repository
- Dependencies installeren (npm install, composer install)
- Tests uitvoeren (unit tests, integratietests)
- Assets bouwen (CSS, JavaScript compileren)
- Deployen naar de productieserver via SSH of rsync
GitLab CI/CD als alternatief
GitLab biedt een geintegreerde CI/CD-oplossing die bijzonder krachtig is. De pipeline wordt gedefinieerd in een .gitlab-ci.yml bestand in de root van je repository. GitLab ondersteunt daarnaast ook environments, review apps en auto-deploy naar Kubernetes clusters.
Git deployment strategieen vergelijken
Er zijn verschillende strategieen voor git deployment, elk met eigen voor- en nadelen.
| Strategie | Downtime | Complexiteit | Rollback | Geschikt voor |
|---|---|---|---|---|
| Direct deployment | Kort | Laag | Git revert | Kleine projecten |
| Blue-green deployment | Geen | Gemiddeld | Instant (switch) | Productieomgevingen |
| Rolling deployment | Geen | Hoog | Geleidelijk | Meerdere servers |
| Canary deployment | Geen | Hoog | Snel | Grote applicaties |
Blue-green deployment uitgelegd
Bij blue-green deployment draai je twee identieke productieomgevingen: "blue" (huidige versie) en "green" (nieuwe versie). Je deployt de nieuwe code naar de green-omgeving, test deze grondig, en schakelt vervolgens het verkeer om van blue naar green. Bij problemen schakel je direct terug.
Best practices voor git deployment
Om je git deployment proces betrouwbaar en veilig te houden, volg je deze best practices:
- Gebruik feature branches - Ontwikkel nieuwe functionaliteit op aparte branches en merge pas naar main wanneer alles getest is
- Automatiseer tests - Laat nooit code deployen die niet door alle tests is gekomen
- Configuratie buiten de repository - Sla wachtwoorden, API-keys en andere gevoelige gegevens op in omgevingsvariabelen, niet in je code
- Database-migraties apart uitvoeren - Voer migraties uit voordat je de nieuwe code deployt om compatibiliteitsproblemen te voorkomen
- Monitoring na deployment - Stel uptime monitoring in om problemen direct na deployment te detecteren
- Documenteer je deploymentproces - Zorg dat elk teamlid het proces kan uitvoeren, niet alleen de lead developer
Met een goed ingericht git deployment proces bespaar je uren per week aan handmatig werk en minimaliseer je de kans op fouten bij het live zetten van wijzigingen op je website.
Git deployment: veelgemaakte fouten vermijden
Bij het opzetten van git deployment worden regelmatig dezelfde fouten gemaakt die tot problemen leiden bij het live zetten van wijzigingen. Ken deze valkuilen en voorkom ze.
De meest voorkomende fout is het committen van gevoelige informatie naar de repository. Wachtwoorden, API-sleutels en databasegegevens horen niet in je codebase. Gebruik een .gitignore bestand om configuratiebestanden uit te sluiten en bewaar gevoelige data in omgevingsvariabelen. Als je per ongeluk geheimen hebt gecommit, is het niet voldoende om ze in een nieuwe commit te verwijderen: ze staan nog in de Git-geschiedenis. Gebruik tools als git-filter-repo om de geschiedenis te herschrijven.
Een andere veelgemaakte fout is het direct deployen naar productie zonder een staging-omgeving te gebruiken. Test je wijzigingen altijd eerst op een omgeving die identiek is aan productie. Dit voorkomt dat bugs, conflicten of configuratieproblemen pas op de live server worden ontdekt. Automatiseer dit proces door je CI/CD-pipeline zo in te richten dat wijzigingen eerst naar staging worden gedeployed.
Vergeet ook niet om je deployment-scripts idempotent te maken. Dit betekent dat het script hetzelfde resultaat oplevert, ongeacht hoe vaak je het uitvoert. Als een deployment halverwege faalt en je het opnieuw draait, mag dit geen problemen veroorzaken. Gebruik conditionele checks en transacties in je migatiescripts om dit te garanderen. Met goede migratiepraktijken en geautomatiseerde tests bouw je een robuust deployment-systeem dat je team vertrouwen geeft bij elke release.
Git deployment: aan de slag met je eerste pipeline
Als je nog geen ervaring hebt met geautomatiseerde git deployment, begin dan met een eenvoudige opzet die je geleidelijk kunt uitbreiden. De eenvoudigste manier om te starten is met een post-receive hook op je productieserver. Dit is een script dat automatisch wordt uitgevoerd wanneer je code naar de server pusht. Het script haalt de laatste code op en herstart indien nodig de webserver.
Een stap verder is het opzetten van een GitHub Actions workflow. Maak een bestand aan in je repository op het pad .github/workflows/deploy.yml. Definieer hierin de stappen die bij elke push naar de main-branch moeten worden uitgevoerd: code ophalen, tests draaien en deployen via SSH. GitHub biedt ruime gratis minutes voor open en private repositories, waardoor je zonder extra kosten kunt starten. Begin eenvoudig en voeg geleidelijk meer stappen toe naarmate je vertrouwen groeit. Een CI/CD-pipeline is nooit af: hij evolueert mee met je project en wordt steeds betrouwbaarder naarmate je meer tests en controles toevoegt aan het proces.
Git deployment: conclusie en volgende stappen
Met een goed ingericht git deployment systeem til je je ontwikkelworkflow naar een professioneel niveau. De voordelen zijn onmiskenbaar: elke wijziging is traceerbaar, terugdraaien is eenvoudig, en samenwerken met meerdere ontwikkelaars verloopt conflictvrij. Begin eenvoudig met een basisworkflow die bij elke push naar main automatisch deployt naar je productieserver. Voeg geleidelijk meer stappen toe: geautomatiseerde tests, linting, beveiligingsscans en notificaties. Documenteer je deployment-proces zodat elk teamlid het kan uitvoeren en begrijpen. Investeer in een staging-omgeving om wijzigingen te testen voordat ze live gaan. Met deze bouwstenen creeer je een betrouwbaar, herhaalbaar deploymentproces dat je vertrouwen geeft bij elke release en de kans op menselijke fouten minimaliseert.
Git deployment best practices voor teams
Bij het werken met git deployment in teamverband zijn er aanvullende best practices die het proces soepeler laten verlopen. Gebruik branch protection rules om te voorkomen dat iemand direct naar main kan pushen zonder code review. Stel verplichte pull request reviews in zodat minimaal een teamlid elke wijziging goedkeurt voordat deze wordt gemerged. Gebruik conventionele commit messages met een vast formaat zodat de geschiedenis leesbaar blijft en automatisch changelogs kunnen worden gegenereerd. Implementeer automatische rollbacks die de vorige versie herstellen als een deployment faalt of als monitoring detecteert dat de nieuwe versie fouten veroorzaakt. Houd je branches kort: feature branches die langer dan een week bestaan worden moeilijk te mergen en veroorzaken conflicten. Met deze practices bouw je een robuuste deployment pipeline die het vertrouwen van het hele team geniet.
