Volgen en oplossen van issues in 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 bijvoorbeeld www.joker.be. 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 een meer algemene noemer, in dit geval 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 onze SPOC (single point of contact) ook uit in de repo zodat zij issues kunnen loggen en de status van gelogde issues kunnen opvolgen. Hoe je die issues nu best logt, vind je onderaan bij 'Issues'.

Het Kanban Board bereik je door naar het project te gaan in Gitlab en dan in de linker sidebar op Issues te klikken. Daaronder krijg je dan vier opties om dieper te filteren, hier klik je op Boards. Hier zie je nu een volledig overzicht per Swimlane (meer uitleg over een Swimlane vind je onder de afbeelding). 

 
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.

Een project in development

  • Open, ofwel Backlog

    Hier worden alle issues in verzameld die nog verwerkt moeten worden, dit zijn issues die zowel werden aangemaakt door de PM als door de SPOC. Indien aangemaakt door de SPOC, assignt hij/zij deze issue aan de PM zodat hij/zij deze kan opvolgen. Dan wordt er ook beslist of dit een bug is (al dan niet binnen garantie) of een uitbreiding. Uitbreidingen worden gelabeld met het label Uitbreidingen. 

  • 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.

Een project dat reeds live staat

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. 

 

“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 -->

 

Hoe kan je nu zo'n issue template gebruiken?

Wel, als je een nieuw Issue toevoegt, zie je onder het Titel veld Choose a template staan. Klik daar op en kies dan 'issue'. Vanaf het moment dat je hier op geklikt hebt, zie je dat de template verschijnt. Om zo volledig mogelijk te zijn bij het aanmaken van een issue zijn er een paar zaken die we moeten weten.

Zo is het belangrijk dat je de URL meegeeft van waar het probleem zich voordoet. Bij Problem/Motivation kan je kort meegeven waarom dit een probleem voor je vormt. Hier willen we vooral wat background informatie zodat we een passende oplossing kunnen voorzien. Steps to reproduce is één van de belangrijkste stappen in het maken van een issue, omdat je hier vertelt hoe je tot het probleem gekomen bent. Idealiter schrijf je hier stap voor stap uit wat je gedaan hebt. Door deze stappen te volgen, zouden we je probleem helemaal moeten kunnen reproduceren. 

Bij Actual result schrijf je nog eens uit wat het probleem is dat je hebt nadat je de Steps to reproduce hebt doorgelopen. Voeg ook altijd een screenshot toe van het probleem. Bij Expected result vertel je wat je verwacht. Heb je een nieuwsitem gepubliceerd en staat het op de verkeerde plaats? Dan zeg je hier op welke plaats het wel moet komen. Zo tasten we ook niet in het duister van wat je verwachtingen zijn.

Is je issue browser of device gerelateerd? Dan kan het ook zeker geen kwaad om die gegevens mee te geven in de issue. Hoe meer info we hebben, hoe beter en sneller we je kunnen verder helpen. 

Mijn issue is klaar, wat nu?

Je hebt je issue klaargemaakt, de issue template gebruikt en alles juist ingevuld? Dan assign je de issue aan de PM. Deze gaat op zijn/haar beurt verder met het opvolgen van de issue en bespreekt samen met de klant in welke sprint versie dit wordt meegenomen. 

 

Milestones

Issues hangen aan milestones, oftewel sprint versies. We bundelen alle issues in onderling overleg samen 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.