In 2015 ging ik aan de slag bij Bossers & Cnossen in Groningen. B&C is van oudsher leverancier van hardware, maar doet onderhand ook veel aan inrichting en beheer van complete automatiserings-omgevingen. Zo verzorgen ze voor hele grote maar ook kleinere klanten bijvoorbeeld de hele kantoorautomatisering, servers, werkstations, netwerk en alles wat er bij komt kijken, meestal gehost "in the cloud" natuurlijk. Klanten besteden dus de hele IT aan B&C uit, en zij zorgen dat het werkt, net zoals bijvoorbeeld het waterbedrijf zorgt dat je thuis water hebt. "IT als water uit de kraan".
B&C heeft een kleine afdeling Webapplicaties, waar applicaties worden gebouwd en onderhouden voor klanten. Veel van die applicaties zijn in de loop van de jaren ontstaan als extra service voor klanten die ook al hardware of andere diensten van B&C afnamen. Het idee daarbij was dat zo'n applicatie dan mogelijk ook weer aan andere klanten kon worden verkocht.
We waren maar met een klein team, en dat betekent dat er een grens is aan het aantal applicaties dat we "in de lucht" konden houden. We kwamen er achter dat we, in plaats van 10 applicaties met moeite up-to-date te houden, liever 1 of 2 applicaties wilden uitbouwen en perfectioneren. Daarom richtten we ons op de meest succesvolle van al die applicaties: Presentatiebeheer.
Presentatiebeheer (inmiddels heet het Spark) is een narrowcasting systeem, dat je als organisatie kunt gebruiken om informatie op schermen te presenteren aan je klanten, je medewerkers of aan wie je maar wil. B&C levert hiervoor natuurlijk schermen, inclusief een bijbehorende thin client, en de klant kan zelf beheren wat er wanneer op welk scherm wordt getoond. Hiervoor hebben we een supermooie en intuïtief werkende applicatie gebouwd, waarin je heel gemakkelijk content kunt beheren, die helemaal in je eigen huisstijl wordt opgemaakt en op je schermen wordt weergegeven. Die applicatie kon daarbij ook koppelen aan allerlei externe systemen om gegevens daaruit weer te geven, bijvoorbeeld over zaalreserveringen, wachtrijen, opbrengst van zonnepanelen, Facebook, Twitter, eigenlijk wat je maar wil.
In 2016 en 2017 hebben we een nieuwe versie van Presentatiebeheer gebouwd. De beheer-applicatie maakten we in AngularJS (1.4). Op de schermen draaide in een browser een Javascript-client en de server-applicaties, die onder meer de gegevens van alle presentaties bijhouden maar ook zorgen voor bijvoorbeeld afbeeldingen en video die in presentaties gebruikt kunnen worden maakten we in Java 8, met Spring Boot 1.5 en later 2.0.
Omdat AngularJS tijdens de nieuwbouw van de applicatie alweer aan een nieuwe versie toe was zijn we gaan kijken wat een overgang naar Angular 2 zou betekenen. Toen bleek we daarvoor best wel veel dingen opnieuw moesten bouwen zijn we ook nog alternatieven gaan overwegen die misschien nog wel beter zouden passen. We kwamen uit op Aurelia, een framework dat is gestart door één van de oorspronkelijke makers van Angular. We waren gecharmeerd van de eenvoud en flexibiliteit van Aurelia, en een performance-test liet zien dat het veel sneller en lichter was dan Angular 2 op dat moment. Dus besloten we om met Aurelia verder te gaan. Daarvoor maakten we van bestaande componenten die we in Angular hadden gemaakt Aurelia-versies en daarbij namen we meteen weer een nieuwe look and feel voor de applicatie mee. We probeerden zoveel mogelijk te blijven leren van hoe gebruikers de applicatie daadwerkelijk gebruikten, om het voor hun zo makkelijk mogelijk te maken.
Naast het bouwen aan onze software waren we veel bezig met het beheersbaar maken en houden van onze ontwikkel-omgeving. Zoals ik al zei waren we met een klein team, en hoe meer we konden automatiseren hoe meer tijd we hadden voor het perfectioneren van de applicatie en hoe kleiner de kans op fouten. Hiervoor hebben we het build- en deploy-proces geautomatiseerd in Bamboo. Dat is een continuous integration oplossing van Atlassian, die ook Jira maakt, waarin we alle issues registreerden en planden in sprints. Versiebeheer van de code deden we met Git, in onze eigen Bitbucket-server. Die is ook van Atlassian, en zo haden we een goed inzicht in welke issues in welke versie waren opgelost en welke code-wijzigingen daarbij horen. We werkten volgens de Gitflow-workflow, waarbij we de productie-versie van de software altijd uit de master-branch konden bouwen. Eventuele productie-problemen losten we op in hotfix branches, en voor nieuwe functionaliteiten maakten we feature branches vanaf de develop branch. Voor elke release maakten we een release-branch, die we uitgebreid testten en daarna mergden naar de master branch.
Onze eigen libraries en NPM modules deployden we naar een Nexus server, die ook diende als proxy voor bijvoorbeeld third-party Maven dependencies en NPM modules. We gebruikten Sonarqube om de code die we gemaakt hebben te analyseren op kwaliteit. Sonarqube gaf ons inzicht in de kwaliteit van de code en ook van de code-coverage, oftewel hoeveel van de code werd afgedekt door unit-tests. Tenslotte waren we bezig met het opzetten van geautomatiseerde integratie-tests, om zeker te weten dat de software ook functioneel bleef doen wat het moest doen.
Ik vind het heel erg leuk om op deze manier met software ontwikkeling bezig te zijn, een groot deel van de tijd besteedden we echt aan het investeren in het product. Een voordeel van werken in zo'n klein en autonoom team is dat we zelf beslisten wat we deden en hoe we dat deden, en het is mooi als wat je samen bedenkt goed blijkt te werken.
OCLC