Hoe is jouw workflow wanneer je een WordPress site bouwt voor een klant? Misschien zoiets als onderstaande:
- Men neme een bestand van de FTP en downloadt dit naar de lokale omgeving.
- Er worden wat aanpassingen gedaan in het bestand.
- Het bestand wordt teruggezet op de FTP.
- De verandering wordt op de live site bekeken.
- Nog niet helemaal tevreden? Herhaal bovenstaande stappen.
In mijn beleving is zo’n workflow voor kleine projecten niet zo’n probleem. Zeker niet tijdens de ontwikkelfase. De veranderingen zijn niet voor het publiek te zien (aangenomen dat de site nog niet geindexeerd is) en het is handig dat ook de klant eenvoudig kan meekijken.
Maar dan gaat de site live. En er komen meer wensen van de klant. Nu wordt het een beetje penibel: Ga je die nieuwe functionaliteiten direct op de live site implementeren?
Over workflow is natuurlijk te discussieren, maar er zijn ook boeken over volgeschreven. Zo kun je eens een snelle google doen op WordPress workflow en je vindt miljoenen resultaten (niet alle relevant!). Een belangrijk deel hiervan betreft versie beheer. Een ander belangrijk deel betreft de mogelijkheid om je code te testen voor je het live zet. Hieronder ga ik kort in op versie beheer en het opzetten van een omgeving om te kunnen testen.
Versie beheer
Wie versiebeheer roept, krijgt als antwoord tegenwoordig vaak Git. Met Git kun je samen werken aan code en ervoor zorgen dat al je veranderingen bewaard blijven. Je kunt werk van verschillende developers samenvoegen en wanneer twee developers in hetzelfde bestand hebben gewerkt kun je het ontstane conflict oplossen. De sleutel om goed met Git te kunnen werken is vaak committen van je veranderingen zodat er een rijke historie ontstaat.
Daarnaast helpt Git je in je workflow. Door branches (aftakkingen) te maken kun je je workflow professionaliseren. Zo is een bekende workflow om tijdens het ontwikkelen te werken in een development branch. Deze aftakking groeit geleidelijk naar een stabiele versie toe die met de master branch (die naar de live omgeving kan worden gepushed) kan worden samengevoegd. Nieuwe functionaliteiten bouw je in kortlevende aftakkingen die je daarna weer samenvoegt met de development tak. Dit type workflow helpt je ook bij het testen.
Development, Staging en Production
Development, staging (of testing) en production is een kreet die vaak in een adem wordt genoemd met versie beheer. In feite komt het neer op een workflow die er als volgt uitziet. De developers hebben ieder hun eigen versie van het project die ze, wanneer ze gaan werken aan het project ophalen van de test (stage) omgeving. Elke developer maakt zijn aanpassingen, test deze lokaal en stuurt ze dan naar de testomgeving. De testomgeving is op een echte webserver die zoveel mogelijk lijkt op de live site, zodat deployment naar de live omgeving zo geruisloos mogelijk gaat: Als je goed getest hebt op de testserver dan zal het in principe ook moeten werken op de live omgeving.
Cowboy coding
De term cowboy coding wordt gekscherend gebruikt voor de workflow die ik aan het begin van dit artikel beschreef. Ga jij over tot een workflow met versiebeheer en goede testmogelijkheden ook nadat de site live staat? Dan is cowboy coding verleden tijd. Uiteraard zal het wat tijd kosten om aan deze nieuwe manier van werken te wennen, maar ja, Rome werd ook niet in een dag gebouwd toch?!
