de 6 kenmerken van een schaalbare organisatie-1

DevOps

Trivento werkt met zelfstandige teams die tijdens de volledige lifecycle verantwoordelijk zijn voor het ontwikkelen, onderhouden en monitoren van software oplossingen voor klanten. Naast het ontwikkelen en onderhouden (development) is een team ook verantwoordelijk voor het in de lucht houden van de ontwikkelde oplossing (operations).

Zo doen we het

Trivento streeft ernaar om een goede relatie op te bouwen met zijn klanten, waarbij klanten zoveel mogelijk ontzorgt worden tijdens de levensduur van de software oplossing.

Om dit goed te kunnen doen maakt Trivento SLA afspraken met haar klanten op het beheren en in de lucht houden van de ontwikkelde oplossing. Trivento acht een SLA noodzakelijk om ook de kennis van de ontwikkelde oplossing up to date te houden, waardoor onderhoud op een applicatie sneller en efficiënter uitgevoerd kan worden.

De teams van Trivento werken op een Agile Scrum wijze intensief samen met de klanten tijdens het realiseren van een oplossing. Dit wil dus zeggen dat features worden geprioriteerd en vervolgens als werkpakketten in een sprint van meestal 2 weken worden ontwikkeld. Trivento heeft in 2009 reeds gekozen voor de Agile Scrum aanpak, omdat het goed past bij de intensieve interactie die nodig is tussen ontwikkelteam en klant (product owner).

Een change of een feature, die als story op de backlog van Jira staat, zal eerst met de klant besproken worden in een refinement sessie. Als duidelijk is wat er gedaan moet worden, dus wat de wens van de klant is, dan zal er door het team een inschatting van de complexiteit gegeven worden. Dit gebeurd d.m.v. een planning poker tijdens een planning sessie. Als de klant akkoord is zal het team story inplannen.

In de story die opgepakt wordt staat ook beschreven hoe deze geaccepteerd moet worden of te wel de acceptatiecriteria. Tijdens het ontwikkelen van de story worden aanpassingen in de code op een aparte branch gezet. Teams van Trivento werken altijd met een versiebeheer systeem. Dit kan zijn Github of Gitlab. Changes van de software die gepushed worden naar het versiebeheer systeem worden automatisch door een bouw en test pipeline opgepakt. Deze bouw en test pipelines staan in Wercker of in GitlabCI. Als een story “af” en deze succesvol gebouwd en getest is door de pipeline, zal deze gereviewd moeten worden. Dit doen ontwikkelaars door in Github een Pull Request of in Gitlab een Merge Request aan te maken. Een of meerdere collega’s zullen de wijzigingen in de code dan reviewen. Pas bij een akkoord van de collega’s mag de change opgenomen worden in de “develop” branch. Ook nu start er weer een pipeline die de geïntegreerde wijzigingen bouwt en test. Als deze automatische pipeline succesvol is, dan zal er automatisch uitgerold worden naar en testomgeving. Deze testomgeving kan op het Apollo platform van Trivento staan.

Als blijkt dat alles goed draait op een testomgeving, worden de wijzigingen van de “develop” branch overgenomen in de “master” branch. Ook nu starten er weer pipelines die het producten bouwen, testen en automatisch deployen naar de test- en acceptatie-omgeving op bijvoorbeeld Apollo. Als de klant akkoord geeft op de wijzigingen die ter acceptatie aangeboden zijn kan met 1 druk op de de knop het product uitgerold worden naar de productieomgeving. Dit alles gebeurd vanuit de pipelines op Wercker of GitlabCI.

Patrick Lanters CTO

Patrick Lanters CTO

Laat hier je
gegevens achter

Patrick Lanters neemt contact met je op