Is code groen in Jenkins genoeg?

Als u niet bekend bent met Jenkins: het is software die het bouwen van een continue integratie (CI)-server met een webinterface vereenvoudigt. Jenkins checkt code uit van een broncoderepository zoals GitHub, bouwt die code vervolgens, test hem en levert er verschillende soorten rapporten over – geslaagd/mislukt, codedekking. Jenkins elimineert niet de noodzaak om scripts voor afzonderlijke stappen te maken, maar het biedt een snellere en robuustere manier om de hele pijplijn van build-, test- en implementatietools te integreren.

Vóór Jenkins moesten ontwikkelaars de vreselijke ervaring van nachtelijke builds doormaken. De enige andere optie die ze hadden was om zorgvuldig te bouwen en te testen op een lokale machine voordat de code werd gecommit, wat in isolatie werd gedaan zonder de commits van iemand anders. Het was duidelijk dat er toen geen garantie was dat de build iemands commit zou overleven. Voer Jenkins in – een direct antwoord op deze beperking.

Het is heel gemakkelijk om met Jenkins aan de slag te gaan. Hier is een korte lijst met basisprincipes die u nodig hebt om aan de slag te gaan:

• Implementeer versiebeheer naar keuze, zoals GitHub
• Schrijf tests voor de belangrijkste onderdelen van uw codebasis en behandel tests als productiecode.
• Zorg voor een geschikte CI (die heb je met Jenkins) waarmee je tests kunt uitvoeren bij elke check-in in de repository, en waarmee je ook je builds kunt implementeren.
• Zie de verschillende componenten van uw software als bouwstenen die moeten passen en goed moeten samenwerken om iets zinvols te worden. Het is niet genoeg dat een specifiek stuk code op zichzelf goed functioneert. Het moet goed integreren met al het andere door middel van continue integratie.

Jenkins geeft je (relatief gezien) snelle feedback over kapotte builds, wat geweldig is, maar alleen als die bugs worden gedetecteerd en onmiddellijk worden verholpen. Meestal worden dergelijke bugs onder het tapijt geveegd omdat uw focus ligt op het halen van implementatiedeadlines. Het hele team moet zich inzetten voor hoge kwaliteit en de waarde begrijpen van het onmiddellijk aanpakken van problemen en technische twijfel tot een minimum beperken.

Geautomatiseerde softwaretests

Nu is hier de spreekwoordelijke vlieg in de zalf. Het probleem met bugs in software is dat ze andere bugs verbergen die andere bugs verbergen, enzovoort. Naarmate de bugs zich opstapelen, wordt het moeilijker om ze te testen en te vinden, wat resulteert in vervelende verrassingen. Maar als er verschillende soorten nuttige geautomatiseerde tests worden uitgevoerd in uw continue integratiepijplijn, weet u wat u moet oplossen zodra een test mislukt. Niet al het testen kan worden geautomatiseerd en het kost tijd om te automatiseren wat kan worden geautomatiseerd, maar dit helpt je om software op een duurzame manier te ontwikkelen en de technische schuld tot een minimum te beperken.

Als we het nu hebben over CI en continue levering, is het niet voldoende om alleen tests te automatiseren en in Jenkins in te voeren. Wat u ook moet doen, is de juiste soorten tests bouwen die gebruiksvriendelijk zijn en helpen om aan de verwachtingen van de klant te voldoen – in wezen de juiste soorten tests ontwerpen en automatiseren. Het schrijven van tests die code op verschillende niveaus onderzoeken, wordt vaak overgeslagen, terwijl onvolledige tests worden opgegeven en nooit worden herschreven.

Dus wat moet je doen? Besteed een aanzienlijke hoeveelheid tijd aan het schrijven van echte, uitgebreide en nuttige tests. De extra inspanning zal later zijn vruchten afwerpen en tijd besparen die wordt besteed aan het opsporen van fouten die door tests hadden kunnen worden gedetecteerd. U kunt in plaats daarvan de foutopsporingstijd besteden aan het schrijven van code voor nieuwe functies.

Denk strategisch na om te bepalen welk soort testen u de beste resultaten zal opleveren. Unittests moeten worden geschreven om uw implementatie van functies te controleren, integratietests om verschillende componenten samen te laten werken, terwijl acceptatietests belangrijke zakelijke vereisten valideren. Zelfs als al uw tests gereed zijn, kunt u verkennende tests uitvoeren om problemen te ontdekken die zelfs Jenkins (automatisering) zou kunnen missen. Het bouwen van software van hoge kwaliteit is zeer complex en het is moeilijk maar noodzakelijk om het goed te krijgen. Het gebruik van de juiste tools helpt programmeurs op weg en ondersteunt het ontwikkelproces.

Iets anders waar ik op wil wijzen, is dat hoe gemakkelijker het is om iets te testen, hoe gemakkelijker het wordt om de kwaliteit ervan te bepalen. Dus als je code zo is geschreven dat het niet mogelijk is om er tests voor uit te voeren, zal het erg moeilijk zijn om bugs te testen en te verwijderen.