Het geheim zit in het proces. Zo leveren we kwaliteitscode voor applicaties van klanten

De meeste mensen denken dat kwaliteit een eigenschap is die je gewoon aan producten toevoegt door er tijd en geld in te investeren. Alsof je een heel slecht gebakken omelet kunt kopen en die kunt verbeteren door hem gewoon langer te bakken. Dat is duidelijk niet waar, en ik zou het niet aanraden, tenzij je graag as eet. Kwaliteit zit ingebed in het proces: vanaf het allereerste begin heb je de juiste tools, goed materiaal en de vaardigheden nodig om alles samen te brengen.

De vergelijking met de omelet is een voorbeeld dat ik graag gebruik in software engineering. Niet alleen om onze klanten uit te leggen hoe softwareontwikkeling werkt, maar ook om mezelf en mijn collega’s eraan te herinneren dat we over kwaliteit moeten nadenken, niet als iets in het product, maar als iets in het proces zelf, van de allereerste codewijziging tot de allerlaatste.

Let op: dezelfde mensen die geloven dat kwaliteit iets is wat je aan een product toevoegt, geloven vaak ook dat kwaliteit duur is, omdat het uiteindelijk iets “extra’s” is waarvoor je moet betalen. Ook dat is niet helemaal waar. Natuurlijk moeten developers wat extra tijd besteden aan het opzetten van de tools en werkwijzen die kwaliteit opleveren, maar dat is nog steeds veel goedkoper dan de omelet opnieuw maken!

Kwalitatieve code leveren in applicaties is als een ei bakken

In deze blogpost wil ik uitleggen welke tools en werkwijzen we bij Elements gebruiken om onze omeletten te bereiden. Voor ons is dat een heel bevredigende ervaring, en voor onze klanten een heel prettige!

Allereerst laten we je graag de keuken zien. Er is geen beter bewijs van kwaliteit dan de klant daadwerkelijk bij het proces betrekken. Meestal treedt de klant op als Product Owner binnen de Agile-methodologie , en bepaalt hij of zij wat er wel en niet in het eindproduct moet komen. Het kan een enorme klus lijken om alle applicatievereisten te definiëren, zeker als het om een grote applicatie met veel functionaliteiten gaat. Daarom wordt het proces opgedeeld in zogenoemde “sprints”, die meestal twee weken duren. Aan het begin van elke sprint specificeren we samen met de Product Owner het werk dat in die twee weken moet worden gedaan. Aan het einde geven we een demo van het opgeleverde werk, zodat de klant indien nodig meer feedback kan geven. Zelfs in de beste restaurants heb je niet zoveel controle!

Onze code automatisch testen, zodat we indien nodig zout kunnen toevoegen.

Vanuit het perspectief van de developer willen we de beste code leveren met zo min mogelijk moeite. Volgens de legende gebruikte de ultieme developer zijn toetsenbord maar één keer, alleen om zijn werk te automatiseren. Grapjes terzijde: wat we echt willen, is code één keer schrijven en daarna nooit meer aanraken. Want als je je code opnieuw moet aanraken, is de enige reden daarvoor dat die in eerste instantie niet goed was. Daarom schrijven we ook tests voor elk stuk code dat we maken, zodat we zeker weten dat alles werkt zoals bedoeld. Vervolgens draaien we die tests automatisch elke keer dat we nieuwe code indienen. Als ook maar één van die tests faalt, staan we niet toe dat de nieuwe wijzigingen in het eindproduct terechtkomen!

Sommige tools helpen ons beveiligingskwetsbaarheden te vinden voordat we naar productie releasen

Dit hangt nauw samen met de Continuous Integration en Delivery pipelines. Dit zijn geautomatiseerde processen die we instellen om bij elke codewijziging te draaien. Ze beperken zich niet tot het uitvoeren van unit tests; we voegen ook tools toe die automatisch code formatting en beveiligingskwetsbaarheden controleren. Deze CI/CD-pipelines regelen ook het deployen van de code (het releasen van een nieuwe mobiele applicatie, API, webfrontend…). We deployen zelden nieuwe code vanaf een luxe strand ergens in Barcelona; dat gebeurt alleen in films. Een machine doet het voor ons: zonder fouten, beter, veiliger en sneller! Een fijn aspect van dit proces is dat de klant geen maanden hoeft te wachten om de gloednieuwe coole feature van zijn app te zien. Hij kan meekijken terwijl het gebeurt en ons feliciteren, of ons de schuld geven omdat de omelet zout mist, zodat wij het kunnen corrigeren.

Tussenliggende servers, zodat we de eieren proeven en monitoren voordat we ze aan de klant serveren.

Het is nu waarschijnlijk eerlijk om te zeggen dat we die wijzigingen niet rechtstreeks naar de uiteindelijke productieserver releasen. Meestal gebruiken we twee tussenliggende servers. Eerst deployen we naar onze interne server, die vooral door ons interne QA-team wordt gebruikt voor tests en security audits. Zij zijn erg bevoorrecht, want zij mogen als eerste de omelet proeven! Als zij zeggen dat hij goed is, deployen we naar wat wij acceptatie noemen, waar de klant de controle heeft. Die controleert of alle gewenste features aanwezig en correct geïmplementeerd zijn. Zodra we goedkeuring hebben, releasen we ze uiteindelijk naar productie.

Een voorbeeld van live health monitoring van een applicatie

Tot slot zorgen we er ook voor dat we de vertering van de omelet monitoren! We beschouwen het project pas als afgerond aan het echte einde, je weet wel, totdat de omelet… nou ja, is uitgescheiden. Een omelet kan heerlijk zijn, maar als je de voedingsstoffen niet goed opneemt, is hij het niet waard. We zorgen ervoor dat we logging- en reportingcode en tools opnemen die ons direct waarschuwen met een volledige error trace en nuttige informatie als gebruikers mogelijk ergens tegenaan lopen. Zo kunnen we het heel snel oplossen.

Zoals je ziet laten we kwaliteit ontstaan vanuit het proces, zowel vanuit de tools die we gebruiken als vanuit onze interne organisatie. Dingen aan het einde proberen te repareren door meer tijd en geld te investeren is simpelweg suboptimaal en zou oneerlijk zijn voor zowel de developers als onze klanten. Nu ken je het geheim: telkens wanneer iemand met je over software praat, denk jij aan omeletten!

‍

Dit is het einde van de blogpost, dus ik waardeer het dat je zover bent gekomen en hoop dat je er iets van hebt geleerd! Als je meer wilt weten over de tools die we hier bij Elements gebruiken, vind je hieronder een min of meer volledige lijst, in ieder geval voor onze backend-technologiestack. En natuurlijk: als je vragen hebt over het proces van het maken van een hoogwaardige applicatie/omelet, laat het ons weten!

Toollijst

Agile-methodologie

• Organisatie
  - JIRA
• Documentatie
  - Confluence
• Communicatie
  - Slack
  - Microsoft Teams

Testen

• Unit tests
  - pytest
• Loadtesting
  - Locust
• Integratietesten
  - cypress

Kwaliteit

• Formatting
  - black
  - isort
  - flake8
• Security
  - safety
  - bandit
• Overig
  - coverage
  - mypy

Deployment

• CI/CD
  - Gitlab CI
• Provisioning
  - Ansible
  - Rancher
• Releasen
  - Docker
  - Helm
  - Harbor
• Orkestratie
  - docker-compose
  - docker swarm
  - Kubernetes

Monitoring

• Logging
  - Sysdig
• Observability
  - istio
  - Kiali
• Metrics
  - Prometheu s
  - Grafana
• Reporting/tracing
  - Sentry
  - Jaeger

‍