Wat is GitLab en hoe werk je ermee?
Auteur: Redactie Domeny.ForSale Gepubliceerd
In het kort: GitLab is een platform om code op te slaan, samen aan wijzigingen te werken en tests en deployments van applicaties te automatiseren. Het gebruikt Git, een systeem dat de wijzigingsgeschiedenis van bestanden vastlegt, en voegt daar hulpmiddelen voor werkorganisatie en kwaliteitscontrole aan toe. Je kunt de dienst GitLab.com gebruiken of GitLab op je eigen infrastructuur draaien.
Waarvoor dient GitLab en hoe verschilt het van Git?
Met Git kun je bijhouden wie wanneer bestanden heeft gewijzigd, versies vergelijken en een eerdere staat van het project herstellen. Het werkt ook lokaal op je computer, zonder account bij een online dienst. GitLab is daarentegen een platform dat gebruikers van Git een gezamenlijke werkomgeving biedt.
De basis van een project is een repository: een verzameling bestanden met hun wijzigingsgeschiedenis. Met GitLab kun je de repository in je browser bekijken, de toegang beheren en voorgestelde aanpassingen bespreken. Naast code kun je er ook documentatie, serverconfiguratie of tekstbestanden van een website in opslaan.
GitLab is geen code-editor of contentmanagementsysteem zoals WordPress. Een ontwikkelaar schrijft doorgaans code in een eigen editor en stuurt de wijzigingen vervolgens naar de repository. Het platform helpt om die wijzigingen te controleren en over te brengen naar de omgeving waarin de applicatie draait.
Hoe werk je samen aan wijzigingen?
Werken in GitLab hoeft niet te betekenen dat je rechtstreeks de hoofdversie van het project aanpast. Een teamlid maakt een branch, een aparte ontwikkellijn voor de code, en legt wijzigingen daarin vast als commits: sets aanpassingen met een beschrijving. Zo kun je een nieuwe functie voorbereiden zonder meteen invloed te hebben op de versie die anderen gebruiken.
Een uitgewerkt voorstel dien je in als een merge request: een verzoek om de wijzigingen samen te voegen met een gekozen branch. Anderen kunnen de code vergelijken, opmerkingen achterlaten en aangeven wat nog moet worden aangepast. Zodra aan de afgesproken voorwaarden is voldaan, worden de wijzigingen samengevoegd. Welke goedkeuringen en toegangsregels nodig zijn, hangt af van de configuratie en de beschikbare functies.
Stel dat een bureau het contactformulier op de website van een klant verbetert. Een ontwikkelaar bereidt de wijziging voor in een aparte branch, een tweede persoon controleert de foutafhandeling en een automatische test controleert of de gegevens correct worden verzonden. Pas na die controles voegt het team de aanpassing samen met de hoofdversie en zet deze op de website.
Voor het melden van fouten en het plannen van taken zijn er issues: meldingen met een beschrijving, een discussie en een verantwoordelijke persoon. Door een issue aan een merge request te koppelen, kun je later niet alleen achterhalen wat er is veranderd, maar ook waarom.
Wat levert CI/CD-automatisering op?
CI/CD staat voor continue integratie en continue levering of uitrol van wijzigingen. Continue integratie houdt in dat het werk van het team regelmatig wordt samengevoegd en de code automatisch wordt gecontroleerd. Continue levering maakt de software klaar voor een release; continue uitrol kan deze vervolgens ook automatisch publiceren in de doelomgeving.
In GitLab leg je zulke stappen meestal vast in het bestand .gitlab-ci.yml in de repository. Samen vormen ze een pipeline: een reeks taken die volgens bepaalde regels worden uitgevoerd. Een runner voert de taken uit: dit is een programma dat opdrachten uitvoert op de infrastructuur die eraan is toegewezen.
Een eenvoudige pipeline voor een website kan:
- De syntaxis en opmaak van de code controleren.
- Tests uitvoeren.
- Bestanden bouwen die klaar zijn voor publicatie.
- Ze naar een testserver sturen en, na handmatige goedkeuring, ook naar de productieserver.
Alleen een project in GitLab plaatsen, zet nog geen volledig deploymentproces in gang. Je moet de taken configureren, zorgen dat er een runner beschikbaar is en de nodige rechten toekennen. Wachtwoorden en toegangssleutels horen niet in de code thuis. Gebruik daarvoor goed beveiligde CI/CD-variabelen of een systeem voor het beheer van secrets. Automatische tests vinden alleen problemen waarop ze controleren; een groen testresultaat garandeert dus niet dat er geen fouten zijn.
GitLab.com of een eigen installatie?
GitLab.com is een dienst die door de aanbieder wordt beheerd. Je hoeft het platform niet te installeren of bij te werken, en ook de server hoef je niet te beheren. Je blijft wel verantwoordelijk voor de projectinstellingen, gebruikersaccounts, toegangsrechten en de bescherming van toegangsgegevens.
Een eigen installatie, aangeduid als GitLab Self-Managed, geeft je meer controle over de infrastructuur en de locatie waar gegevens worden opgeslagen. Daar staat tegenover dat je zelf voor updates, monitoring, back-ups en beveiliging van het systeem moet zorgen. Een installatie op een bedrijfsserver is niet automatisch veiliger.
Voor een klein team zonder systeembeheerder is een gehoste dienst meestal een praktischer startpunt. Een eigen installatie kan zinvol zijn bij specifieke eisen aan het netwerk, integraties of gegevens. Controleer voordat je kiest in de officiële documentatie en prijslijst van GitLab de actuele opslaglimieten, de manier waarop CI/CD-taken worden afgerekend en of het gekozen abonnement de benodigde functies bevat.
GitLab versus GitHub en de eerste stappen
GitLab en GitHub zijn verschillende platforms die Git gebruiken. Beide bieden opslag van repositories, beoordeling van wijzigingen, beheer van issues en automatisering van werkprocessen. In GitHub heet het equivalent van een merge request een pull request. Voor automatisering kun je er onder meer GitHub Actions gebruiken.
Baseer je keuze op de benodigde integraties, toegangsrechten, automatiseringskosten en de ervaring van het team. Het overzetten van de Git-repository zelf is vaak relatief eenvoudig, maar het migreren van issues, discussies en deploymentconfiguraties vraagt om een aparte voorbereiding.
Maak om te beginnen een privéproject met een README-bestand waarin je het doel van het project beschrijft. Bereid vervolgens een kleine wijziging voor in een aparte branch en open een merge request. Zo leer je de basis van de workflow kennen voordat je automatisering en toegang tot servers toevoegt.
Lees ook
