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 we zelf hosten (self-managed, dus niet de SaaS op gitlab.com), op eigen servers bij Scaleway. Geen trendhoppen: we wilden minder versnippering over tools, meer grip op de keten van code tot deployment, en dezelfde kwaliteitslat over alle klantprojecten.

We leggen uit waarom we die switch maakten, waar GitLab in onze situatie net iets beter past dan GitHub (zonder GitHub af te kraken), en wat je daar als klant merkt.

Git blijft Git, het platform verandert wel

Even rechtzetten: Git is het versiebeheersysteem. GitHub en GitLab zijn platforms eromheen: hosting, review, automatisering, enzovoort. Of je dat een merge request of een pull request noemt, 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 plek om te bouwen, te testen, te reviewen en gecontroleerd uit te rollen, met duidelijke rechten en een audit trail.

Voor klanten verandert niets aan jullie aanspreekpunten of aan wat we leveren. Wel kunnen we intern sneller dezelfde standaard op elk project leggen. En als er vragen zijn over releases of goedkeuringen, kunnen we duidelijk terugwijzen naar wat wanneer is gemerged en getest.

Wat we bedoelen met “eigen GitLab”

Concreet draait GitLab bij ons op virtuele servers bij Scaleway die wij zelf inrichten en beheren: updates, back-ups, netwerk en toegang onder onze regie. We gebruiken dus geen gitlab.com als centrale plek waar de code staat; applicatie en data blijven op infrastructuur die we zelf kiezen en beveiligen. Scaleway levert de compute en het netwerk; de stack (GitLab, runners, policies) beheren wij. Zo houden we de volledige toolchain in handen, van repository tot CI-runners, zonder voor dat stuk afhankelijk te zijn van een SaaS voor het platform zelf.

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. 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 in zit, hangt af van je editie en configuratie). Bij ons ging het niet om “GitHub kan dat niet”, maar om self-managed GitLab als vaste standaard over alle projecten, met volledige regie over runners en hosting. Met veel parallelle projecten merken we dat er minder per repository hoeft te worden bijgeschaafd.

2. Zeggenschap over data en infrastructuur

Code en build-artifacts zijn strategisch spul: intellectueel eigendom van klanten en van onszelf. Omdat GitLab bij ons op eigen beheerde servers draait—in ons geval gehost in Europa via Scaleway—bepalen we zelf waar die data landt, hoe die wordt beveiligd en hoe back-ups lopen, en welke externe koppelingen we toelaten. Dat past bij een Europese, compliance-bewuste manier van werken. Cloud GitHub kan dat overigens ook goed aanpakken (enterprise- en regio-opties bestaan); voor ons was volledige regie over de stack, op infrastructuur die we zelf uitkiezen, de doorslag.

3. Herhaalbare pipelines

GitLab CI beschrijf je in de repository, meestal via .gitlab-ci.yml. Daardoor kunnen we templates en patronen hergebruiken: dezelfde stappen voor testen, linting, build en deploy naar staging, met aanpassingen per project waar nodig. Minder ad-hoc scripts, meer voorspelbaar gedrag. Dat helpt bij onboarding op een nieuw project en vangt regressies eerder op.

4. Review en merge-afspraken afdwingbaar

Goede softwareontwikkeling is meer dan code committen. Je wil discussie, goedkeuringen, en regels zoals: pipeline moet groen zijn vóór merge. GitLab bundelt dat strak met issues en milestones, en waar we het inschakelen ook 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 koppelen.

Waar GitHub sterk blijft (en terecht populair is)

We blijven realistisch: GitHub is een topplatform. De community rond open source is groot, veel ontwikkelaars en klanten werken er al op, 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.

Self-hosted kan ook met GitHub via GitHub Enterprise Server. “Eigen infrastructuur” is dus niet exclusief aan GitLab verbonden. Bij ons kwam de keuze neer op totaalplaatje, kostenmodel, regie over runners en hosting, en welk platform het best aansloot bij hoe we al werkten. Geen wedstrijd om “de beste tool ooit”.

Het gaat niet om het logo bovenaan je scherm. Het gaat om herhaalbare kwaliteit: wat is er gemerged, wie heeft goedgekeurd, welke tests zijn geslaagd. Dat moet overal even helder zijn.

Dat hangt samen met hoe we over onderhoudbare code denken: lees ook waarom kwaliteitssoftware tijd en moeite vergt — strakke reviews en groene pipelines hebben daar baat bij.

Migreren doe je niet “even”

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 op de middellange termijn: minder uitzonderingen, meer uniformiteit. Wie hetzelfde overweegt, plant best een gefaseerde migratie en verhuist niet alles in één nacht.

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 oplossingen die alleen op de machine van één iemand draaien. 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. Concrete realisaties vind je bij cases; het overzicht van web, apps en automatisering op oplossingen.

Tot slot

Onze overstap naar self-managed GitLab op Scaleway is een investering in controle, consistentie en schaal. Geen statement dat elke organisatie hetzelfde moet doen. GitHub blijft een uitstekend alternatief; voor Codelines past deze combinatie—GitLab als platform, Europese cloud als onderliggende server—beter bij hoe we vandaag bouwen en leveren.

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