Als softwarebureau leeft je workflow in Git: branches, reviews, builds, releases. Jarenlang deden we dat grotendeels op GitHub — en dat werkte prima. Toch hebben we recent beslist om stap voor stap te centraliseren op GitLab dat op onze eigen servers draait (self-managed, niet de SaaS op gitlab.com). Geen trendhoppen, wel een keuze die past bij hoe we vandaag willen werken: minder versnippering over tools, meer grip op de keten van code tot deployment, en dezelfde kwaliteitslat over alle klantprojecten.

In dit artikel lees je waarom we die switch maakten, waar GitLab voor ons net iets beter aansluit dan GitHub in deze setup (zonder GitHub af te branden), en wat dat praktisch betekent als je met ons samenwerkt aan maatwerksoftware.

Git blijft Git — het platform verandert

Even rechtzetten voor wie niet dagelijks in terminologie duikt: Git is het versiebeheersysteem; GitHub en GitLab zijn platforms eromheen (hosting, review, automatisering, enz.). Hoe je zo’n voorstel ook noemt — merge request of pull request — het idee is hetzelfde: code voorstellen, bespreken, goedkeuren, samenvoegen.

Wat wél verandert, is waar die stappen gebeuren en hoe diep repository, CI/CD, artifact registry en kwaliteitspoorten in elkaar zitten. Voor ons team betekent GitLab concreet: één omgeving om te bouwen, te testen, te reviewen en gecontroleerd uit te rollen, met duidelijke rechten en audit trail.

Voor klanten verandert niets aan jullie aanspreekpunten of aan wat we leveren. Wél kunnen we intern sneller dezelfde standaard toepassen op elk project — en bij vragen over releases of goedkeuringen duidelijker terugwijzen naar wat wanneer is gemerged en getest.

Wat we bedoelen met “eigen GitLab”

Concreet draait GitLab bij ons op infrastructuur die wij zelf hosten en beheren — eigen servers, met updates, back-ups, netwerk en toegang onder onze regie. We gebruiken dus geen gitlab.com als centrale plek waar de code slaapt; de applicatie en de data blijven op omgevingen die we zelf kiezen en beveiligen. Daarmee hebben we eigenaarschap over de volledige toolchain, van repository tot CI-runners, zonder afhankelijk te zijn van een externe SaaS-host voor dat stuk.

Waarom dit voor Codelines werkt

1. DevOps in één lijn

GitHub heeft sterke bouwstenen — denk aan Actions, de GitHub Container Registry naast je repository, Packages, Dependabot — en teams die dat strak uitlijnen, kunnen evengoed een geïntegreerde flow van bouwen, testen en deployen hebben.

GitLab profileert zich nadrukkelijk als één DevOps-platform: naast Git-hosting horen daar CI/CD, container registry en planning bij, plus inzichten rond kwaliteit en security (wat er precies beschikbaar is, hangt af van je GitLab-editie en configuratie). Voor ons ging het niet om “GitHub kan dat niet”, maar om self-managed GitLab als één vaste standaard over alle projecten, met volledige regie over runners en hosting. Voor een bureau met veel parallelle projecten merken we dat als minder configuratie die per repo afdwaalt.

2. Zeggenschap over data en infrastructuur

Code en build-artifacts zijn strategisch materiaal: intellectueel eigendom van klanten en van onszelf. Omdat GitLab bij ons op eigen servers draait, bepalen we zelf waar die data fysiek staat, hoe die wordt beveiligd en hoe back-ups lopen, en welke externe koppelingen we toelaten. Dat sluit aan bij een Europese, compliance-bewuste manier van werken — zonder te suggeren dat cloud GitHub dat per se niet kan (GitHub biedt enterprise- en regio-opties), maar voor ons was volledige regie over de stack de doorslag.

3. Herhaalbare pipelines

GitLab CI beschrijf je in de repository (typisch via .gitlab-ci.yml). Daardoor kunnen we templates en patronen hergebruiken: dezelfde stappen voor testen, linting, build en deploy naar staging, aangepast per project waar nodig. Minder ad-hoc scripts, meer voorspelbaar gedrag — wat onboarding op een nieuw project versnelt en regressies vroeger vangt.

4. Review en merge-afspraken afdwingbaar

Goede softwareontwikkeling is meer dan “code committen”. Je wil discussie, approvals, en regels zoals “pipeline moet groen zijn vóór merge”. GitLab bundelt dat strak met issues, milestones en — waar we het inschakelen — kwaliteits- en security-overzichten in dezelfde omgeving. GitHub kan vergelijkbaar via branch protection en Actions; het verschil voor ons zit vooral in één consistente workflow op onze eigen infrastructuur, zonder telkens extra services te moeten verbinden.

Waar GitHub sterk blijft — en terecht populair is

We blijven realistisch: GitHub is een topplatform. De community rond open source is enorm, de adoptie bij ontwikkelaars en bij klanten die zelf op GitHub werken is hoog, en het ecosysteem aan integraties, marketplace actions en AI-ondersteuning (zoals Copilot) is indrukwekkend. Voor veel open-source projecten en voor teams die bewust in dat ecosysteem blijven, is GitHub vaak de beste keuze.

Ook self-hosted kan met GitHub via GitHub Enterprise Server — dus “eigen infrastructuur” is niet exclusief aan GitLab verbonden. Voor ons kwam de afweging neer op totaalplaatje, kostenmodel, regie over runners en hosting, en welk platform het best aansloot bij hoe we al werkten — niet op een wedstrijd wie “de beste tool ooit” is.

Het draait niet om het logo bovenaan je scherm. Het draait om herhaalbare kwaliteit: wat wordt gemerged, door wie goedgekeurd, en welke tests zijn geslaagd — dat moet overal hetzelfde helder zijn.

Migreren doe je niet “even”

Eerlijkheid verplicht: zo’n switch kost tijd en aandacht. Repositories verhuizen of spiegelen, CI-pipelines herschrijven, gewoontes van het team bijsturen, integraties (issues, hooks, deploy-keys) nalopen. De winst zit in de middellange termijn: minder uitzonderingen, meer uniformiteit. Wie hetzelfde overweegt, doet er goed aan een gefaseerde migratie te plannen en niet alles in één nacht te verplaatsen.

Wat jij als klant merkt

Direct merk je aan de buitenkant vaak weinig — en dat is goed. Indirect win je mee aan voorspelbaarheid: duidelijke releasepaden, minder “alleen op de machine van X”-oplossingen, en bij vragen over wat er wanneer live ging kunnen we terugvallen op merge history en pipeline-resultaten. In sectoren waar traceerbaarheid telt (kwaliteit, security, audits), helpt dat om vertrouwen te onderbouwen.

Wil je weten hoe wij van idee tot oplevering werken? Lees meer over software op maat en onze aanpak op over Codelines.

Tot slot

Onze overstap naar GitLab op eigen servers is een investering in controle, consistentie en schaal — geen statement dat elke organisatie hetzelfde moet doen. GitHub blijft een uitstekend alternatief; voor Codelines past self-managed GitLab beter bij hoe we vandaag bouwen en leveren.

Vragen over onze ontwikkel- en releasepraktijk? Neem contact op — we leggen het graag toe.