Gezamenlijk schrijven we honderden regels code per dag, vaak is de code bedoeld om nieuwe features te ontwikkelen en soms om bugs op te lossen. Om te voorkomen dat we daarnaast ook nog druk bezig zijn om alles naar een omgeving te verplaatsen waar het getest kan worden door onze software tester en/of projectmanagers, hebben we hier een hoop geautomatiseerd. 

Bitbucket

Onze code staat allemaal bij Bitbucket. Daardoor hebben we alles veilig opgeslagen in de cloud, waarbij we de toegang kunnen beperken voor bepaalde personen. Bitbucket heeft zelf nog een aantal handige functies zoals Pipelines. Dat is een tool die verschillende taken automatisch uitvoert zodra wij wijzigingen aan de code uploaden naar Bitbucket.

Een standaard set taken voor onze roadmap projecten is bijvoorbeeld;

• Statische code analyse (Codacy)
  • Voldoet de code aan onze richtlijnen qua code stijl?
  • Staan er geen ongebruikte stukken code in?
  • Worden er aannames gedaan in de code die nooit gehaald kunnen worden?
• Code testen (PHPUnit)
  • Is bij een gegeven invoer de uitvoer zoals we verwachten?
• Packages / updates van packages installeren (composer)

Hiermee kunnen onze developers de garantie afgeven dat de code netjes is en voldoet aan de afgesproken vereisten aan de software, met een set aan gedefinieerde regels.

Statische code analyse

Codacy is een tool waarmee we onder andere checken of de code voldoet aan onze richtlijnen qua code stijl. Dat heeft verder niet met de werking van de code te maken, maar puur met de opmaak qua aantal spaties, witregels, etc. 

Dit zorgt ervoor dat de code leesbaar en begrijpbaar blijft, ook voor nieuwe collega’s die we mogen verwelkomen. 

Code testen

Om te kunnen garanderen dat de software blijft werken zoals afgesproken, schrijven we voor de kritieke onderdelen van de software verschillende code tests. Hier beschrijven we de situatie vooraf en wat deze moet zijn na het uitvoeren van een stuk code.

Hiermee controleren we eigenlijk dat een aanpassing aan de code niet per ongeluk ergens anders een ongewenst effect heeft.

Packages en updates installeren

We maken gebruik van Composer voor het beheer van (externe) uitbreidingen aan onze software. Composer plaatst hiervoor twee bestanden in de codebase, namelijk één om aan te geven welke (kleinere) plugins geïnstalleerd staan en één om aan te geven welke versies (en afhankelijkheden) er precies benodigd zijn. 

Deze bestanden worden bijgewerkt in het geval we een extra stukje software nodig hebben, of een update installeren. Vervolgens weet Composer op de test en live omgeving precies welke versie we nodig hebben en zal deze dan ook downloaden en installeren. 
Voordat Composer alle plugins downloadt, checkt hij eerst of alle plugins compatibel zijn met elkaar. Als de ene plugin aangeeft dat hij versie x van een taal of framework nodig heeft en een andere plugin juist versie y, geeft Composer dit aan. Vervolgens kijken we of de desbetreffende plugin geüpdatet of vervangen kan worden zodat alles weer stabiel naast elkaar kan draaien.

Meer inhoudelijk over updates kun je vinden in onze volgende blog.