WebGang/CityGang

We gebruiken Git(Lab) voor ons stockpi project

Dit is een voorbeeld van hoe een workflow kan zijn. Verschillende takken zijn van de main afgetakt door verschillende gebruikers. Die werken aan een bepaald stukje software, bv de Setup procedure van het programma. Git laat toe dat verschillende mensen tegelijk aan het project werken (hier bv rood, blauw en groen), en helpt om die stukjes nadien in elkaar te puzzelen.

Die ontwikkeling gebeurt “lokaal” op de computer van die ontwikkelaar. De ontwikkelaar haalt eerst een kopie af van de “main”, wat clonen genoemd wordt, en geeft die een naam; bv dev-hq=development headquarter, een naam die de developer op het hoofdkwartier van Webgang gekozen heeft.

Hij maakt een “tak” of branch voor het werk waaraan hij bezig is, en geeft die ook een naam, waaraan je kan zien waar hij aan werkt, hier bv de setup procedure in Dev01Setup.

Als dat stuk klaar is wordt het met commit + push online gebracht en is het al af te halen/in te zien door anderen. Denkt de ontwikkelaar dat het ver genoeg klaar is brengt hij het naar de “test” branch, onderaan op de afbeelding.

In de test branch worden alle ontwikkelingen samen gebracht, en in ons programma “testen” we die uit; enerzijds de lib compileren en anderzijds de cli en de app die de lib gebruiken uitproberen. Als een programam crasht proberen we dat te documenteren. Anders: We noteren opmerkingen en correcties.

Goedgekeurd? Als de combinatie goed werkt gaat alles naar de “main”.

Het toeval (enigzins geholpen door Marthe) wil dat we een professionele developer in de studio hebben, Claes, en we toetsen onze workflow bij hem af.

Hij veegt de oranje testbranch op het witbord hierboven weg, en vult aan:
- de eigen tak van de ontwikkelaar wordt “feature branch” genoemd (omdat een bepaalde “nieuwe functie” wordt bijgemaakt – kan uit een tickeet komen).
- tijdens de otnwikkeling kan een programmeur al collega’s raadplegen
- peer review: een collega-programmeur die enigzins op de hoogte is van het onderwerp, gaat je code nakijken om denkfouten eruit te halen enz.
- Hij kan een soort “ok” geven (merge request) waardoor het programma klaar wordt gezet om in de main branch opgenomen te worden.
- Voor het integreren van die tak in de main helpt het platform; je kan “merge request” aanvinken, er commentaar bij ingeven, en het systeem documenteert en zet een knop klaar om dat te aanvaarden door de beheerder van de main branch; dat kan een ontwikkelaar zijn, of een coördinator, binnen het platform kunnen rollen verdeeld worden met bijhorende rechten.
- automatisch testen: in het gitlab (of ander git-) platform kan je een aantal voorgeprogrammeerde testen laten lopen; die kunnen semantisch zijn (bv spellingscontrole bij documentatie), of functioneel: compileert het programma, kan het programma gestart worden, en zelfs het gebruik van het programma kan getest worden.
- Als een nieuwe main gemaakt is, wordt die ook nog eens uitvoerig getest (met de automatische procedures).
- de “feature branch” wordt verwijderd.

Ook op voorhand wordt er bepaald wat er allemaal moet geprogrammeerd worden, je kan daarvoor een ticketing systeem gebruiken (“type feature request”) dat op het gitlab (of ander) platform voorhanden is. Dat is hetzelfde principe van wat wij zouden doen, maar natuurlijk verloopt het daar gestructureerder. De tickets kunnen afgevinkt worden, gekoppeld aan een “merge” in de main, gekoppeld aan andere systemen enz.