Volgen en oplossen van issues met Gitlab

Issues en Gitlab. Er is al veel over geschreven, gediscussieerd en zelfs vergeleken, maar toch gebruikt elk bedrijf het op zijn manier. Zo ook Wieni.  

Issues in Gitlab

Bij elk nieuw project wordt er een repo aangemaakt in Gitlab (zie afbeelding hieronder) met als naam - meestal - de volledige url van de website. Een uitzondering op die regel zijn bijvoorbeeld de websites vier.be, vijf.be en zestv.be. Deze websites hebben allemaal dezelfde codebase en worden dus niet apart als repo aangemaakt in Gitlab, deze worden verzameld onder SBSTV.

Een overzicht van projecten in Gitlab

Een overzicht van projecten in Gitlab

Kanban Board

Vervolgens zetten we een Kanban Board op (van het Japanse kan 'visueel' en ban 'kaart of bord). Dit gebruiken we om het proces van het development van een website in kaart te brengen, zowel voor ons intern als voor de klant. 

Meestal nodigen we de klant ook uit in de repo zodat zij issues kunnen loggen en de status van gelogde issues kunnen opvolgen. Maar soms zitten klanten niet in Gitlab en sturen ze eventuele bugs door via mail.   

Overzicht van issues op een Kanban Board in Gitlab

Swimlanes

In het Kanban board staan verschillende rijen, Swimlanes zoals we die in jargon noemen. Swimlanes bepalen de status binnen je project. De Swimlanes zijn verschillend voor een project dat nog in development is, en dus nog niet live staat, en voor een project dat reeds live staat.

  • Open, ofwel Backlog

    Hier worden alle issues in verzameld die nog verwerkt moeten worden, meestal aangemaakt door de PM. Vanaf dit moment assignt de PM het ook aan de juiste persoon.

  • In Progress

    Dit zijn, zoals het woord het zelf al aanhaalt, issues waar de developers aan bezig zijn.

  • Dev Done

    Als een issue klaar is voor een developer, zet hij deze in Dev Done. Dit betekent dat de issue klaar is maar nog niet op de testing omgeving staat en dus nog niet kan getest worden door de PM of de klant.

  • To Test On Stag

    Vanaf het moment dat een issue in To Test On Stag staat, kan het op de testing omgeving getest worden en wordt de issue ook weer aan de PM gehangen die dat op zijn/haar beurt weer doorgeeft aan de klant.

  • Closen Is een issue OK voor de klant, dan closed hij/zij de issue. Indien niet in orde, wordt er feedback in het ticket verzameld en gaat het issue weer naar de PM, die het dan op zijn/haar beurt weer doorgeeft aan de juiste persoon.

Als een project reeds live staat, komen er twee Swimlanes bij:

  • To production

    Het voortraject is nog steeds hetzelfde als hierboven beschreven, maar de klant gaat het issue niet meer sluiten bij To Test On Stag maar sleept het naar To Production. Zo weten we dat het issue klaar is om naar productie te gaan.

  • To Final Test

    Als we de issues dan live zetten, sleept de PM alle issues naar To Final Test en test hij/zij deze op de live omgeving. Indien in orde gaan de issues naar de klant, die de issues dan op zijn/haar beurt gaat testen en closen indien in orde.

Issues

Het belangrijkste element voor de Kanban Boards zijn de issues. En vooral de manier waarop die issues opgebouwd worden. Binnen Wieni hebben wij een Issue Template gemaakt die door zowel klanten als developers als PM’s aangehouden wordt. Dit zodat er geen verwarring over een issue kan ontstaan en het niet meerdere malen op en af gestuurd wordt om nu het eigenlijke probleem te weten te komen.

Nog een belangrijke regel is dat degene die het issue aanmaakt, ook degene is die de issue sluit.   

“No link no fix”

## URL
<!--- Provide a link to a live example -->

## Problem / Motivation
<!--- Why the issue was filed -->

## Steps to Reproduce (for bugs)
<!--- Provide an unambiguous set of steps to reproduce this bug. Include code to reproduce, if relevant -->
1.
2.
3.
4.

## Actual result
<!--- If describing a bug, tell us what happens instead of the expected behavior -->
<!--- A screenshot can be shown using ! -->

## Expected result
<!--- If you're describing a bug, tell us what should happen -->
<!--- If you're suggesting a change/improvement, tell us how it should work -->

 

Milestones

Issues hangen aan milestones. Dit wordt vooral gebruikt als een project reeds live staat. We bundelen alle issues in 1 milestone. Die milestone krijgt een datum en op die datum zetten we alles live. Op die manier weet iedereen perfect wat er van zich verwacht wordt en wanneer iets live moet.

Due dates

Sommige issues hebben ook due dates. Dit zijn vooral kleine issues die op capita maandag (link naar capita maandag) aangepakt worden. De due dates worden afgestemd met klanten dus het is zeer belangrijk dat deze datum gerespecteerd wordt en niet zelf aangepast wordt. Dit kan enkel in samenspraak met de PM.