Bij het ontwikkelen van onze projecten komt uiteraard veel development kijken en omdat we het een achterhaald principe vinden om onze code regel voor regel zelf te schrijven, werken we met functies en objecten. Bij veel van onze klanten gebruiken wij dezelfde pakketten en functionaliteiten in de codebases zodat we zelf stabielere en bekendere code hebben. Omdat we dit niet zelf continue willen kopiëren tussen verschillende projecten en klanten gebruiken we een ‘packagemanager’. Simpel gezegd een tool die dit soort ‘pakketten’ bijhoudt en het makkelijk maakt om deze te updaten.

Een goed voorbeeld van een packagemanager die bij ons gebruikt wordt is Composer. Dat concept gaan we nú niet uitleggen (lees dat gerust hier), maar wat wel interessant is, is dat je Composer natuurlijk veel breder kunt inzetten. In deze post gaan we in op hoe wij composer nog meer in onze praktijk inzetten.

Onze case

Wij ontwikkelen voornamelijk veel Magento e-commerce platformen en bijbehorend maatwerk. Dat werk hebben we, doordat we veel in doorlopende sprints werken, heel regelmatig onderhanden. Maar we hebben ook vaak te maken met WordPress omgevingen die we voor onze klanten vaak inzetten als een headless CMS voor binnen hun Magento front-end. Aan die omgevingen wordt minder vaak gewerkt en dat goed bijhouden is best een werkje.

Omgevingen opzetten met Composer

Om goed met onze gemiddelde case om te gaan en te voorkomen dat het goed up-to-date houden van de WordPress omgevingen erbij inschieten, hebben we een tijdje terug alle WordPress CMS-omgevingen volgens hetzelfde principe opgezet; via Composer. Dit houdt in dat we, in plaats van alle plugins en thema’s in een codebase per klant op te slaan, we alles op 1 centrale plek beheren en vervolgens alleen het klant-specifieke maatwerk nog deel wordt van de codebase van de klant. Dit centrale gedeelte, te beheren via Composer, kun je zien als een soort blauwprint voor een klant die je installeert zodra je een omgeving opzet of release uitvoert.

Het resultaat

Naast dat het ons tijd scheelt en het daardoor laagdrempeliger wordt om uit te voeren, vergroot deze actie ook onze kwaliteit. Door Composer op deze manier in te zetten, hebben we een aantal zaken bereikt.

  • Alle projecten werken op eenzelfde consistente manier. In onze praktijk betekent dit dat als een collega bij ons aansluit die het project nog nooit geopend heeft, hij of zij ook direct aan de slag kan met een structuur die ze gewend zijn van een andere omgeving.
  • De externe en interne plugins zijn heel makkelijk te updaten. WordPress zelf en de bijbehorende plugins kan je nu updaten met 1 commando, waarbij we dus heel snel, zonder klant-specifieke werkwijzen, ieder project met 1 commando volledig naar onze gewenste versie up-to-date kunnen krijgen .
  • Een gemakkelijk reproduceerbaar project overstijgend versie-overzicht doordat we de 2 bovenstaande punten hebben uitgevoerd.
  • Een automatisch release-proces wat uniform is voor al onze projecten en klanten, waarbij we bijvoorbeeld niet hoeven in te loggen op de server van klanten en afhankelijk zijn van andere domein-specifieke kennis en/of handelingen.

Meer slimme ontwikkelingen?

Het is onderdeel van ons werk om continue te kijken naar slimme verbeteringen in ons werk. Wil je hier zelf mee aan de slag of ben je benieuwd naar andere ontwikkelingen waar we aan werken, houd dan ons Github account in de gaten.

Graag zo'n developement team voor je aan het werk hebben?

Vertel ons meer over je project en behoeften.

Neem contact met ons op