DevOps deel 1: Tien-minuten build

Om een goed beeld te geven hoe wij DevOps aspecten toepassen binnen het Cloud Development team hebben we onze DevOps Engineer, Jeroen Schouten, gevraagd om een blogreeks te schrijven. In deze serie blogs zullen wij alle aspecten langsgaan die binnen het DevOps spectrum passen. We trappen af met het domein ‘Build’ en zullen daarna het proces volgen met deel twee het domein testing.

In deze blogpost lees je hoe wij bij DIJ gebruik maken van het 10-minute build principe voor al onze projecten. Het is een best practice wat uit de Extreme Programming wereld komt waarbij de codebase volledig automatisch wordt gebouwd (ge-build). Daarnaast voert het tijdens het bouwen geautomatiseerde tests, en een aantal andere checks, uit. We ontwerpen elk bouwproces zo dat het binnen tien minuten voltooid is. Het voordeel hiervan is dus dat we te allen tijde controleren en detecteren of de software nog naar behoren werkt. Het past dus perfect in ons DevOps gedachtegoed.

Bitbucket Pipelines

De Builds worden uitgevoerd op ‘Bitbucket Pipelines’, een CI/CD tool van Atlassian. Bitbucket Pipelines sluit naadloos aan op andere producten van Atlassian die we ook gebruiken, zoals Bitbucket en Jira. Zo’n build wordt uitgevoerd op het moment dat een developer zijn wijzigingen pushed met Git. Volledig geautomatiseerd start de build die kan slagen of falen. Zonder een geslaagde build kan en mag de wijziging nooit gemerged worden. Het laten slagen van de build wordt hiermee topprioriteit.

Snelle feedback loop

Door bewust de build snel te houden, en dat is een uitdaging op zich, zorgen we ervoor dat de developer snel feedback krijgt. Is er een test gefaald? Voldoet de code niet aan onze standaarden? Door deze snelle feedback zijn de gevonden problemen snel inzichtelijk waardoor ze snel verholpen kunnen worden. Een bug die optreedt maanden na een release zal vele malen moeilijker op te lossen zijn, omdat men uit moet zoeken wat er aan de hand is.

Continuous Integration

Het idee van de tien-minuten build past in ons Continuous Integration gedachtegoed, wat op zijn beurt weer een DevOps best practice is. Bij Continuous Integration worden wijzigingen continu, volledig geautomatiseerd, geïntegreerd met de bestaande code base. De tien-minuten build is de uitvoering van dit gedachtegoed, Met de nadruk op snelheid, dus binnen tien minuten.

We houden de builds snel

De meeste builds van projecten van DIJ vallen binnen de XP richtlijn van een tien-minuten build. Als DevOps Engineer steek ik tijd en moeite in het onderhouden en verbeteren van de builds en zorg ik ervoor dat ze ook snel blijven. Elke minuut die ik van de build af haal heeft als gevolg dat een developer, voor elke push, een minuut minder hoeft te wachten. Voor een grote groep developers zoals bij DIJ, die tot wel tientallen keren per persoon per dag builden, Is de tijdswinst enorm en snel behaald.! Daarnaast hoeven developers zich niet bezig te houden met onderhoud van de 10-minuten builds.

Parallel

In het voorbeeld hieronder, een PHP applicatie, zie je het resultaat van een build die, overigens ruimschoots, voldoet aan de tien-minuten richtlijn. De build is in een aantal stappen opgesplitst. We installeren PHP dependencies en installeren en compilen frontend assets. Vervolgens doen we een aantal checks:

• Er wordt gecheckt of er syntax fouten zijn door de code te linten
• Er wordt gecheckt of code automatisch refactored kan worden
• Er wordt gecontroleerd of de code aan onze coding standards voldoet
• Met statische analyse vangen we fouten en bugs af
• We voeren de volledige testsuite uit inclusief Feature tests, Integration tests en Unit tests

Deze stappen worden parallel uitgevoerd hetgeen er voor zorgt dat de uiteindelijke build tijd ruimschoots onder de tien minuten blijft.

Tot slot

Wil je ook kwalitatieve, testbare, code schrijven? Focussen op nieuwe features in plaats van bugfixing doen? Met mij samenwerken om de build-tijden nog sneller te maken? Kijk dan op onze vacatures pagina.

Geschreven door: Jeroen Schouten