Naarmate een bedrijf groeit merk je dat sommige manieren van werken die in het begin prima voldeden niet meer toereikend zijn. In een duister ver verleden werkten we niet eens in testomgevingen. Aanpassingen in de code deed je toch gewoon direct op de site? Ook al ging de site dan soms kapot. Inmiddels werken we met meerdere teams tegelijkertijd aan projecten en hebben we onze werkwijze flink gestroomlijnd. Laat me je meenemen in de wereld van de automatische bouwstraat!
Lekker met z’n allen een website in elkaar zetten.. toch?
Zoals in praktisch ieder vak merk je onmiddellijk dat in teamverband iets oplossen een compleet andere aanpak vereist dan wanneer je alleen aan een project kan werken. Alles op je eigen manier en je eigen tempo doen is een koud kunstje, met z’n tweeën na elkaar (bijvoorbeeld een front-end developer gevolgd door back-end developer) maakt het al wat lastiger aangezien je rekening moet houden met de persoon aan wie je het werk overdraagt. Bij Elephant zijn we de afgelopen jaren aardig gegroeid met als gevolg dat er projecten voor maatwerk websites opgepakt werden waarbij trapsgewijs werken geen optie was: meerdere developers moesten tegelijk features opleveren. Dat bracht onmiddellijk een paar problemen naar boven.
Het overzicht terug krijgen met een versiebeheersysteem
Een van de eerste problemen is dat je niet tegelijk hetzelfde bestand kunt aanpassen. Soms is dit echter wel nodig of (vaker nog) weet je niet eens dat je een bestand aanpast waar iemand anders ook aan heeft gewerkt. Om een goed overzicht te krijgen van wat er nou precies is veranderd, gebruiken we het versiebeheersysteem “git”. Dit systeem bekijkt wat er allemaal veranderd is, geeft je de mogelijkheid om jouw aanpassingen te vergelijken met de aanpassingen van iemand anders en zorgt er tot slot voor dat je alles kunt samenvoegen tot een bestand. Probleem opgelost.. Toch?
Tests, tests en nog meer tests
Ook al wordt de gemiddelde developer vaak genoeg vergeleken met een robot ( 😉), het blijven toch ook gewoon mensen. En hoewel we het niet altijd willen toegeven maken we allemaal wel eens fouten. Ook al denkt een developer bijvoorbeeld dat hij de aanpassingen van de andere developer goed heeft samengevoegd, er is altijd de mogelijkheid dat het niet zo is. Het kan namelijk niet dat iedere developer de volledige werking van iedere feature weet in een project (dit is waarom documentatie zo belangrijk is). De oplossing voor dit probleem is tests. Automatische tests. Deze zorgen ervoor dat de functionaliteit altijd op een bepaalde manier wordt uitgevoerd waarna er vervolgens een simpel antwoord uit komt rollen: deze feature werkt nog wel of werkt niet meer!
Altijd maar weer die tests
Dus alle developers zijn tests aan het schrijven voor hun projecten. Een project loopt inmiddels een paar maanden en er is een mooie hoeveelheid tests geschreven. De developers beginnen echter meer en meer te klagen. Waarom? “We kunnen niet meer snel ontwikkelen omdat we iedere keer tien minuten moeten wachten op al die honderden tests.” Iedere keer als ze iets ontwikkelen moeten ze een hele batterij aan tests uitvoeren om te controleren of alles nog steeds wel werkt en dat moet ook nog eens op hun eigen, niet altijd even snelle, laptops. Vanaf dit punt begint de bouwstraat echt interessant te worden.
Lekker automatiseren die handel!
Er zijn honderden services en programma’s die zichzelf scharen onder de verzamelnaam “bouwstraat”. In bijna alle gevallen komt het neer op het volgende:
- Een server “ergens”, dit kan in de cloud zijn of lokaal bij een bedrijf
- Een softwarepakket dat je de mogelijkheid geeft om bepaalde taken te definiëren en automatisch te laten uitvoeren
- Een onderliggende koppeling met een versiebeheersysteem en/of een andere “trigger”
Deze krachtige server is zo ingericht dat het bepaalde taken zo snel mogelijk kan uitvoeren. In plaats van dat iedere developer zelf de tests uitvoert kan de server dit dus veel beter en sneller. Zodra een developer code aanpast in het versiebeheersysteem ziet de bouwstraat dit. De bouwstraat haalt deze nieuwe versie van de website vervolgens op, maakt een nieuwe virtuele omgeving aan op basis van de instellingen die developers hebben gedefinieerd en begint daarop alle tests uit te voeren. Uiteindelijk komt hier een resultaat uit dat naar de developer wordt gestuurd en in een overzicht komt te staan met alle testresultaten. Hierdoor kunnen alle developers onmiddellijk zien wat er mis is, door wie het kwam en wat er gedaan moet worden om het te fixen.
Optimaliseren, optimaliseren, optimaliseren
Aangezien we de bouwstraat zelf (per project) kunnen inrichten is het voor ons mogelijk om de menselijke fouten er in bijna iedere stap van het proces uit te filteren. Zo is het voor je website bijvoorbeeld enorm belangrijk dat alle bestanden die worden verstuurd naar de gebruiker maximaal geoptimaliseerd zijn. Hoewel we het soms maar over enkele KBs aan data hebben, kan dit snel oplopen wanneer het over meerdere bestanden gaat. Het verschil tussen een goede score en een slechte score van Google PageSpeed is soms kleiner dan je denkt.
Voordat wij een site doorzetten naar de liveomgeving ‘minificeren’ we alles. Bestanden worden samengevoegd, alle witruimte wordt eruit gehaald, namen worden korter gemaakt, opmerkingen in de code worden verwijderd: alles om een zo klein mogelijk bestand te creëren. Dit is echter een stap die de developers zelf moeten doen voordat ze een nieuwe versie van de website live zetten. Het kan dus voorkomen dat een developer dit vergeet of denkt dat een andere developer dit al heeft gedaan. De oplossing: definieer het proces gewoon als een stap in de bouwstraat en het zal gedaan worden iedere keer nadat een developer code in het versiebeheersysteem aanpast!
En na het bouwen?
De bouwstraat is een enorm breed begrip. Er zijn honderden varianten, services en applicaties die allemaal overlappende voor- en nadelen hebben. Wat voor ons een belangrijk punt was, is dat “na het bouwen” ook de mogelijkheid moest zijn om de code direct door te zetten naar een server. Aangezien het onacceptabel is dat er overal wachtwoorden rondslingeren van servers of dat er door meerdere mensen tegelijk een nieuwe versie wordt live gezet is het belangrijk dat centraal wordt geregeld.
Goed, nadat onze bouwstraat alle tests heeft gedaan en alle stappen succesvol heeft uitgevoerd, geeft deze in een overzicht de mogelijkheid om de site door te zetten naar een van onze servers (bijv. een staging/test of productie omgeving). Door gebruik te maken van de wachtwoordkluis in de bouwstraat hoeven de developers nooit de wachtwoorden te zien en/of te kopiëren wat het, naast het feit dat het een hoop gedoe scheelt, ook een stuk veiliger maakt. Ik kan nog een half uur doordrammen waarom de bouwstraat handig is, welke problemen het fixt en (niet aan de baas vertellen) wat voor leuk speelgoed het soms is maar dan wordt deze blog veels te lang. Als je het toch wil horen kun je me natuurlijk gewoon een berichtje sturen!
Lang verhaal kort: Bij grotere projecten zijn bouwstraten simpelweg onmisbaar. Ze stroomlijnen het proces, zorgen voor geautomatiseerde en geforceerde kwaliteitschecks en maken het leven van de developer een stuk makkelijker. En je weet wat ze zeggen: Een gelukkige developer is een goede website… Ja toch?
