Meer controle en minder werk. Ook in jouw branche.
Snelle en veilige factuurafhandeling voor elke organisatie.
Snelle en veilige factuurafhandeling voor elke organisatie
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 jou te communiceren. Mijn naam is Ivan Malykh en ik ben ontwikkelaar bij Payt. Om je iets meer inzicht te geven in onze software proberen we iedere maand een engineering blog te schrijven. Ik geef je 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.
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.
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 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.
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:
We streven naar 100% en zitten op het moment van schrijven gemiddeld op iets hoger dan 90%.
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.
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.
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.
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.
