Engineering blog: Automatiseer alles!

Illustratie van: Engineering Blog Payt

Share this article

Ivan Malykh
Geschreven door Ivan Malykh
Ivan is een ontwikkelaar bij Payt. Zijn focus ligt vooral op het frontend team, maar ook backend trekt zijn aandacht. Ivan is bereid om beter te worden in technisch schrijven, dus laat het hem vooral weten als je feedback hebt.

Wat is de makkelijkste manier om op de hoogte te blijven van wat er qua engineering bij Payt gebeurt? Wat ons betreft bieden technische blogs een geweldige kans om dit met u te communiceren. Mijn naam is Ivan Malykh en ik ben ontwikkelaar bij Payt. Om u iets meer inzicht te geven in onze software proberen we iedere maand een engineering blog te schrijven. Ik geef u een inkijkje bij Payt.

Toen ik dit artikel begon, schreef ik een introductie voor één van de tools die door ons frontend team gebruikt wordt - Create React App. Het doel hiervan was om te vertellen hoe deze tool ons veel tijd en moeite had bespaard bij het kiezen, installeren en configureren van de verschillende ondersteunende 3rd party packages. Mocht je geïnteresseerd zijn in dat artikel, lees dan hier verder.

Gaandeweg kwam ik tot de conclusie dat het eerste Payt software engineering artikel, in plaats van de diepte in te duiken, een tikkeltje algemener mag zijn. Ik heb er dus voor gekozen om het doel van dit artikel iets aan te passen. We gaan het vandaag hebben over verschillende maatregelen in onze workflow die de productiviteit van het engineering team verhogen en ervoor zorgen dat wij ons volledig kunnen focussen op het ontwikkelen van nieuwe functionaliteiten.

Maar eerst een beetje achtergrond over onze software stack.

Payt biedt de meest complete software op het gebied van debiteurenbeheer. Deze software bestaat uit een aantal web-based applicaties. Hoofdzakelijk zijn het de Debiteurenbeheer app en Debiteurenportaal app. Deze twee applicaties worden “gevoed” met data uit één en dezelfde backend applicatie.

De backend applicatie van Payt bestaat -op het moment van schrijven- onder andere, uit de volgende technologieën:

Frontend applicaties van de Payt applicaties gebruiken onder andere deze technologieën:

Backend en Frontends praten met elkaar door middel van REST en GraphQL API’s en zijn gehost op de Amazon AWS infrastructuur.

Payt bestaat op dit moment iets langer dan acht jaar. In die jaren is het systeem gegroeid en flink uitgebreid met verschillende processen, functionaliteiten en de business logica die daar bij hoort. Het onderhouden van zo’n hoeveelheid logica is niet triviaal, maar zeker niet onmogelijk.

Testen, testen en nogmaals testen.

Het klinkt misschien vanzelfsprekend, maar veel bedrijven maken geen gebruik van een enkele vorm van tests in hun software.

Het ontwikkelen van de nieuwe functionaliteiten bij Payt gaat altijd gepaard met het uitvoeren van de tests. Deze tests kunnen op verschillende manieren uitgevoerd worden. Bij Payt hebben we er voor gekozen dat onze tests door developers geschreven en uitgevoerd worden. De zogenaamde Test-Driven Development. Bij het ontwikkelen van een functionaliteit dient de ontwikkelaar daarvan de zogenaamde unit-tests te schrijven. Deze unit-tests zijn een onderdeel van de code. Wanneer een andere ontwikkelaar met een nieuwe functionaliteit aan de slag gaat en per ongeluk de bestaande functionaliteit breekt, dan waarschuwt test-suite daarover.

Git, Github en Reviews

Git is een versiebeheer tool. De meest gebruikte functionaliteit van Git bij Payt is de zogenaamde “branches”. Een branch is een aftakking van de bestaande productcode t.b.v. het ontwikkelen van een nieuwe functionaliteit in isolement van de werkende productiecode. Wanneer de functionaliteit afgerond is en de tests geschreven zijn, kan de ontwikkelaar haar/zijn werk ter review aanbieden. Github - een platform voor development samenwerking via Git - biedt een mogelijkheid om de Pull Requests aan te maken. Een Pull Request is het verschil tussen de hoofd branch en de branch van de nieuwe functionaliteit (“feature branch”). Een vereiste voor het samenvoegen van een Pull Request met de hoofd branch is dat de geautomatiseerde checks slagen en dat één of twee collega’s de code goedkeuren.

Geautomatiseerde checks

Zoals ik hierboven al vertelde, zijn de tests onderdeel van de code. Bij het ontwikkelen van een feature kan een developer tests uitvoeren om er zeker van te zijn dat de code werkt. Onze test-suite bestaat ten tijde van schrijven uit 11.051 tests. Sommige daarvan testen de integratie tussen de verschillende onderdelen en zijn daarom langzaam. Het zou erg zonde van onze tijd zijn als we, alvorens de ontwikkeling van een functionaliteit, alle elf duizend tests zouden moeten draaien.

Daarom hebben wij een extern systeem dat er voor zorgt dat elke Git commit op de hoofd branch volledig getest is. Zo’n systeem (Continuous Integration of kortweg CI) zorgt er ook voor dat de feature branches, voordat ze door andere ontwikkelaars gereviewd worden, getest worden.

Naast de unit-, acceptatie-, en integratietests zijn er ook een aantal andere checks die ervoor zorgen dat de kwaliteit van de code gewaarborgd is. Een paar daarvan zijn:

  • Check op de percentage van de code dat met tests is behandeld
    We streven naar 100% en zitten op het moment van schrijven gemiddeld op iets hoger dan 90%.
  • Check op de code stijl
    De code stijl check zorgt ervoor dat de manier waarop de code geschreven is op één lijn zit. Een duidelijke en consistente code stijl maakt het makkelijker voor de nieuwe teamleden om zich bekend te maken met de code. Maar ook de bestaande teamleden kunnen sneller in een onbekend deel van de applicatie duiken.
  • API compatibiliteit check
    De backend en de frontends bij Payt zijn onafhankelijke code-bases, elk met een eigen Git repository. De frontend UI is afhankelijk van de data die via de API door de backend geleverd wordt. Frontend verwacht ook een bepaalde datastructuur. Deze check zorgt er voor dat developer bekend is met de zogenaamde “breaking” changes in de API.

Wanneer één van de checks niet aan de kwaliteitseisen voldoet, moet de desbetreffende developer de fouten of onvolkomenheden corrigeren. Haar of zijn werk mag voor die tijd niet naar de hoofd branch uitgerold worden.

Deployments

Developers zouden geen developers zijn als ze niet al hun werk zouden automatiseren. Zo is ook de uitrol van de ontwikkelde functionaliteiten bij Payt geautomatiseerd. Elke nieuwe functionaliteit - getest en goedgekeurd - wordt geheel automatisch naar onze servers uitgerold.

To do

Ondanks de hoeveelheid van de geautomatiseerde workflows, heeft het engineering team van Payt nog steeds een boel uitdagingen. Bijvoorbeeld, dat we minder tijd hoeven te besteden aan de configuratie, administratie, en andere herhalende en automatiseerbare taken. En juist meer tijd kunnen besteden aan de ontwikkeling van nieuwe functionaliteiten en de uitbreiding van bestaande functionaliteiten van onze applicaties.

Zo werken we, bijvoorbeeld, op dit moment aan de automatisering van de opbouw van de servers waar applicaties op draaien. De bedoeling is dat onze infrastructuur vastgelegd is in de code. Daarmee hebben we straks één blauwdruk van de software die vereist is voor het draaien van onze applicaties. Dat versnelt de uitrol van de nieuwe server instances en zorgt voor consistentie tussen de verschillende machines.

Tags:

Gerelateerde artikelen

Get it. Together. Voor en door onze gebruikers
Payt is er voor iedereen. Onze missie is om de best mogelijke financiële software te leveren voor onze klanten en hun debiteuren. Dankzij onze dagelijkse toewijding om dit doel te behalen, hebben wij reeds al meer dan 10.000 gebruikers aan mogen sluiten en ontvangen wij fantastische reviews van ze waar wij natuurlijk enorm trots op zijn. Tegelijkertijd bracht ons dit ook op een idee. Hoe kunnen wij de betrokkenheid op ons platform vergroten én iets terugdoen voor onze gebruikers waar wij zo trots op zijn? Het antwoord was snel gevonden: Get it. Together.
Payt Dental Stadium Tour, een rondje langs de velden
Het is begin juli. Utrecht. Om half elf sluiten de automatische deuren zich van Stadion Galgenwaard. Het einde van een reeks stadionbezoeken door Nederland. Een reeks waarin we 300 mondzorgprofessionals mochten begroeten om te luisteren naar de verhalen van Vertimart, Webova en Payt. Met voor Payt elke avond een leuke mix van bestaande klanten en geïnteresseerde praktijken. De terugreis naar huis is een mooie gelegenheid om terug te blikken op de lessen van deze rondgang.
5 jaar shirtsponsor van FC Groningen
De laatste 5 jaar is Payt sponsor geweest van FC Groningen. Vanaf 2017 tot 2019 waren we hoofdsponsor van de club en daarna trotse shirtsponsor. Maar aan alle dingen komt een eind. Na dit seizoen stoppen we als sponsor van de club. Het is een prachtig avontuur geworden waarin we veel hebben geleerd. In dit artikel leg ik uit hoe wij als team tegen de initiële keuze hebben aangekeken en welke lessen wij onderweg tegenkwamen.