Deployment & Git

Genoten van deze podcast? Gelukkig stopt het voor jou dan niet met één aflevering.
Beluister hier onze andere podcasts.

Wanneer je een website aanpast, doe je dit meestal lokaal. Als je die aanpassingen dan effectief wilt doorvoeren op je website, dan ga je die ‘deployen’. Dit moet je doen omdat je website niet lokaal, maar op een server staat. Die updates effectief uitrollen (deployen) kan gebeuren op verschillende manieren.

(s)FTP

Hoewel het vaak gebruikt wordt voor kleine websites, is ftp een protocol dat eigenlijk niet veilig is. Omdat de connectie met de server bij ftp clear text is, kan een eventuele hacker op het netwerk alle data makkelijk bekijken. Daarom bestaat er ook een secure variant: sftp.

Daarnaast is er bij ftp ook geen sprake van versiecontrole. Wacht, versiewat? Wanneer je ervoor kiest om de aanpassingen van je website eerst lokaal uit te voeren, is version control erg handig. Zo ga je zeker geen fouten maken in je productieomgeving. 

Elke wijziging kan je onder een bepaalde naam opslaan, en je kan ook altijd teruggaan naar een vorige versie. Vergelijk het een beetje met de version history van je documenten in Google Drive. Daarnaast heb je bij versiecontrole ook de mogelijkheid om met meerdere mensen aan hetzelfde project te werken. De meest bekende version control is Git.

Global Information Tracker, meer bekend als GIT, is een source code management systeem dat volledig open source werkt. Voorlopers van Git waren CVS en Subversion. Git zelf werd in 2005 ontwikkeld door Linus Torvalds, die we ook kennen van de Linuxkernel. Ten opzichte van CVS en Subversion bevat Git een heel groot voordeel, want Git maakt het mogelijk om ook lokaal aanpassingen uit te voeren zonder een connectie te hebben met de remote server

Hoe werkt GIT dan eigenlijk?

Wel, dat wordt even heel technisch. 

1. Om te beginnen maak je een lokale 'repository', dat is een map die je met een git-commando omvormt tot een speciale git-map. 
2. Dan zet je je projectbestanden hierin. Je voegt dus bestanden toe die aangepast zijn. 
3. Telkens als je een kleine wijziging klaar hebt, commit je deze aanpassing met een bepaalde message zodat je weet wat deze aanpassing werkelijk inhoudt. 
4. Tenslotte push je dit naar de remote origin of server (Git push) zodat iedereen deze changes ook kan zien.

Een Git pull werkt dan weer in de omgekeerde richting van een push, logisch toch? Met een Git pull haal je de laatste update van de remote server om die aanpassing lokaal te kunnen bewerken. Die acties kunnen allemaal via je terminal, maar er bestaan ook mooie gui’s (graphical user interfaces) om hiermee aan de slag te gaan.

Met Git flow kan je in het gebruik van Git natuurlijk nog wat verder gaan. Hierbij deel je al je verschillende omgevingen op in branches: een andere versie van de code die een beetje zijn eigen leven zal leiden. Zo kan je bijvoorbeeld je aanpassingen uitvoeren en committen op je development-omgeving en nadien deze code mergen naar je staging-omgeving. Na het oplossen van eventuele conflicten is de code samengevoegd en zijn je aanpassingen ook doorgevoerd op je staging-omgeving. Dezelfde oefening kan je dan ook doen voor je master- of productieomgeving. 

Om je Git flow volledig te maken worden ook het soort aanpassingen dat je doorvoert opgedeeld in branches: features en bugfixes. Een feature is de ontwikkeling van een nieuwe functionaliteit op je website. Een bugfix is de oplossing van een bestaande fout in je code. Dat hier een ander proces achter schuilgaat is dus logisch: bugfixes moeten veel sneller worden geïmplementeerd dan nieuwe features. Met het toevoegen van deze branches blijven je development- en stagingomgeving altijd werken en komt er geen code in terecht die er misschien niet in hoeft te zitten.

Rechtstreeks vanop de webserver Git gebruiken is mogelijk maar kan je beter niet doen. Naast het feit dat dit het niet heel veilig is, is het ook niet de meest praktische manier van werken. Je kan beter vanuit een lege directory vertrekken, je branche binnenhalen in die directory en van daaruit deployen.

Maar hoe kan je dan best deployen? Dat kan bijvoorbeeld met Rsync, een CLI-tool die ervoor zorgt dat je remote code op de server terecht komt. Rsync zal daarbij de metadata in je bestanden vergelijken, en daardoor enkel updaten wat er aangepast werd.

Magallanes of Capistrano zijn leuke deployment tools die de versie van het script op je PC naar de server kunnen sturen. Ze werken met 'releases' en kunnen verschillende stapjes voor, tijdens en na het kopiëren van de bestanden uitvoeren. Bijvoorbeeld: afbeeldingen voorbereiden, services herstarten, tekst indexeren, enzovoort.
 

Zoals de woorden het zelf zeggen is een deployment tool er om de developer verder te helpen. Geen enkele tool is noodzakelijk, maar het gebruik ervan zorgt wel voor efficiëntie. 

We vertrekken dan ook altijd vanuit de kennis en behoefte van de developer. Voor de ene ontwikkelaar is het gebruik van Git al een grote stap. Dan beperken we ons tot het begeleiden van het gebruik van Git en deployment via een script op de pc.

Voor developers die meer deploymentkennis hebben, is het belangrijk om ook hier nononsense te communiceren. Wat is er nodig voor dit project? Hoeveel developers werken eraan mee? Hoe groot is het project en wat is het budget? Het gebruik van verschillende tools en de toepassing van CI/CD klinkt altijd interessant en we werken daar graag aan mee. Maar de business case moet kloppen! ;)

Heb je na het lezen van dit artikel de goesting te pakken gekregen? 
Dan is onze reeks over Kubernetes misschien wel iets voor je!