Welkom bij weer een nieuwe blog over Coqfoss, ons interne project waarin we nieuwe dingen te leren door samen te werken. In deze reeks blogs nemen we je mee in de technieken die we gebruiken en delen we de ervaringen die we opdoen.
In de vorige blog is al kort verteld over wat we van plan zijn om te bereiken met Coqfoss. In het format van een project willen we onderlinge interactie houden en van elkaar leren. Het idee is om samen een product te ontwikkelen dat ons ook meerwaarde biedt. Doordat wijzelf en onze andere collega’s de gebruikers zijn, is het makkelijk om feedback te krijgen op wat we maken. Ook is het fijn dat wij voor dit product de stakeholders zijn, waardoor het prioriteren van werk samen bepaald kan worden.
Randvoorwaarden
Tijdens de kick-off sessie hebben we eerst bekeken hoe we de juiste randvoorwaarden kunnen scheppen om snel echte waarde te kunnen realiseren. Om dat te doen, hebben we een aantal afspraken gemaakt:
- We bepalen gezamenlijk welke features we willen realiseren en in welke volgorde.
- We proberen alles zoveel mogelijk gezamenlijk te doen, zodat iedereen eigenaarschap over de code blijft houden.
- We proberen de focus te leggen op het creëren van waarde en niet alleen op de techniek.
- Concessies op gebied van kwaliteit maken we niet.
- We proberen complexiteit zoveel mogelijk te beperken.
- We proberen om de applicatie zo te ontwerpen, dat deze later makkelijk open source kan worden gemaakt.
- We stellen technische keuzes zo lang mogelijk uit.
We kwamen verder op het idee om het werkproces redelijk vrij te laten. We definiëren een backlog met daarop bepaalde thema’s en werken aan één thema tegelijk. Als we tevreden zijn met de functionaliteit die we hebben gemaakt onder een thema, gaan we door naar een volgende. Pas als we bezig gaan met een volgend thema, gaan we op detail- of featureniveau nadenken over de technische implementatie.
Welke features
Met deze afspraken in het oog bespraken we daarna het wat: welke features denken we te willen gaan maken. Daar kwamen veel mooie thema’s (of epics) uit die de onderlinge verbinding kunnen vergroten en het leven makkelijker kunnen maken. Voorbeelden zijn een overzicht van wie welke boeken in huis heeft, een kalender waarin we makkelijker evenementen, zoals kennisavonden en uitjes, kunnen plannen en een hulptool voor declaraties. Uit die lijst hebben we een backlog kunnen destilleren en gelijk ook kunnen prioriteren.
Walking skeleton
Toen we een beeld hadden van het wat we willen maken en onder welke voorwaarden, konden we concrete keuzes gaan maken over de techniek. We besloten de repository in Gitlab te stoppen en ook de backlog daar onder te brengen. Verder besloten we om zo snel mogelijk een ‘Hello World’ door een pipeline te laten maken en te deployen. Zodoende kwamen we tot het ‘refinen’ van onze eerste epic, waarin we eigenlijk niks anders doen dan zorgen dat de technische voorwaarden staan om in het vervolg zo snel mogelijk features naar productie te brengen. Dat wordt ook wel eens het ‘walking skeleton’ genoemd. De features die we voor dit eerste epic definieerden zijn toen als volgt opgeschreven:
- Opzetten van een lege repository
- Issue tracker vullen met de bedachte epics en features
- Het bouwen van een ‘Hello World’ applicatie
- Het opzetten van een build pipeline
- Het opzetten van een deployment pipeline
De volgende stap was het maken van de technische keuzes. Voor de build- en deployment pipeline besloten we ook Gitlab te gebruiken. Verder besloten we de applicatie op te zetten op basis van Kotlin, Maven en Spring Boot en Docker te gebruiken als build target. Door voor bekende technologieen te kiezen houden we in eerste instantie de complexiteit beperkt. De optie om alsnog spannendere dingen te doen houden we natuurlijk open.
In de volgende blogs zullen we dieper ingaan op het realiseren van deze eerste epic. We gaan het daar hebben over hoe wij denken netjes een Maven multimodule project met Kotlin op te zetten, hoe we in Gitlab de CI en CD hebben geregeld en hoe we met JIB een productieklaar Docker image bouwen.
