Uitrollen, uploaden, toepassen — de essentie van termen en verschillen

Wat betekent „uitrollen", „uploaden", „toepassen"

„Uitrollen" — de meest algemene term die het publiceren van een nieuwe versie van een softwareproduct, functie of wijziging betekent. „We hebben de update uitgerold", „we hebben de fix uitgerold", „we hebben de release uitgerold" — in alle gevallen gaat het erom dat de wijziging beschikbaar is geworden voor gebruikers. De term veronderstelt een vrij grote actie: meestal wordt de hele versie uitgerold, niet een enkel bestand.

„Uploaden" — een meer specifieke term die het uploaden van bestanden, gegevens of artefacten naar een server of repository betekent. „Upload de build naar de server", „upload de scripts naar de DB", „upload de assets naar de CDN". In tegenstelling tot „uitrollen" impliceert de term niet dat het geüploade beschikbaar is geworden voor gebruikers — bestanden kunnen op de server staan maar nog niet aan de applicatie zijn gekoppeld. Nuance: „uploaden" wordt ook gebruikt voor het verzenden van code naar een repository („ik heb het naar GitHub geüpload").

„Toepassen" — een term die het toepassen van een wijziging bovenop een bestaande versie betekent. „Migratie toepassen", „patch toepassen", „config toepassen". Het belangrijkste verschil — de wijziging wordt er bovenop gelegd zonder volledige vervanging. Als „uitrollen" het starten van een nieuwe versie in plaats van de oude is, dan is „toepassen" het toevoegen van een wijziging aan wat al werkt. De term is wijdverbreid in de context van databases (migraties) en patchreleases.

Aanvullende termen uit hetzelfde semantische veld: „uitrollen" (een wijziging verspreiden over alle servers in het cluster), „terugdraaien" (de vorige versie herstellen), „per ongeluk deployen" (per ongeluk de verkeerde versie deployen). Al deze werkwoorden beschrijven handelingen met code als een fysiek object dat kan worden „gerold", „gegoten" en „teruggedraaid".

Oorsprong van de slangtermen

De term „uitrollen" komt van de autometafoor: „de auto uit de garage rijden". Wanneer de code klaar is voor release, wordt deze „uitgerold" — naar buiten gebracht, beschikbaar gemaakt voor gebruikers. De metafoor verspreidde zich begin jaren 2000 met de opkomst van continuous delivery-praktijken, toen releases regelmatig werden in plaats van jaarlijks. „We hebben vandaag een rollout" — betekent releasedag.

De term „uploaden" heeft zijn wortels in het vroege web, toen websites via FTP naar servers werden geüpload. „Bestanden uploaden naar de server" — letterlijk bestanden overdragen via het protocol dat werd geassocieerd met het „gieten" van gegevens. Het woord is blijven hangen, hoewel moderne deployment CI/CD-pipelines gebruikt in plaats van FTP-cliënten. Interessant feit: in het Engels is het analoog „push" (push to server), niet „pour". Het Russisch heeft een andere metafoor gekozen.

De term „toepassen" komt uit de productieomgeving: „een wiel monteren", „een moer vastdraaien". In de context van software — een wijziging toepassen op een bestaand systeem, zoals schroefdraad op een bout wordt aangebracht. In databases is de term bijzonder organisch: migraties worden precies „toegepast" (apply) en „teruggedraaid" (rollback). Rollback — een van de weinige Engelse termen die een nauwkeurig Nederlands equivalent heeft: „terugdraaien".

Verschil tussen termen in verschillende contexten

In de context van databases: migraties worden „toegepast", gegevens worden „geüpload", de schemaversie wordt „uitgerold". Als er een nieuwe kolom moet worden toegevoegd — wordt een migratie toegepast. Als er testgegevens moeten worden ingevoegd — wordt een dump geüpload. Als de databasestructuur volledig verandert — wordt een nieuw schema uitgerold. Het verschil weerspiegelt verschillende bewerkingen: apply, insert/load, deploy.

In de context van DevOps: „uitrollen" — de pipeline starten, „uploaden" — een Docker-image naar het registry uploaden, „toepassen" — een configuratie op de server toepassen via Ansible. Voorbeeld: „eerst uploaden we de image naar het registry, dan passen we de config toe op de server, en pas dan rollen we de release uit". Elke term komt overeen met een aparte fase van de CI/CD-pipeline.

In de context van mobiele ontwikkeling: „uploaden" — de build naar App Store Connect of Google Play Console sturen, „uitrollen" — publiceren in de app store, „toepassen" — de update leveren via het in-app updates-mechanisme. Voor iOS betekent „uitrollen" het doorlopen van Review, voor Android — rollout via Play Console. Tijdschaal: „uploaden" duurt minuten, „uitrollen" — uren of dagen (vanwege de review).

Fasen van het releaseproces: van commit tot productie

Fase 1: Builden (Build). De code wordt gecompileerd, het artefact (binary, Docker-image, APK/IPA) wordt gemaakt. De CI-server start de build na elke commit in de hoofdtak. Het resultaat van de build — een deployment-ready artefact met een unieke versietag (semantic versioning of commit hash). Als de build faalt — stopt de hele pipeline, krijgt de ontwikkelaar een melding.

Fase 2: Testen (Test). Unittests, integratietests, linters, beveiligingscontrole (SAST) worden uitgevoerd. Deze fase mag niet langer dan 10–15 minuten duren — als het langer duurt, verliezen ontwikkelaars de context en schakelen ze over naar andere taken. Snelle feedback — het belangrijkste principe van CI/CD. Volgens Puppet State of DevOps 2023 doen teams met snelle tests (<10 min) 3 keer zoveel releases.

Fase 3: Deployment naar staging (Staging Deploy). Het artefact wordt geïmplementeerd in de staging-omgeving, identiek aan productie. Op staging worden E2E-tests, smoke-tests en indien nodig handmatige QA-tests uitgevoerd. Als op staging een regressie wordt ontdekt — wordt de release geblokkeerd, worden wijzigingen teruggestuurd voor correctie.

Fase 4: Rollout naar productie (Production Deploy). Het artefact wordt op de productieservers geïmplementeerd. Afhankelijk van de deploymentstrategie (rolling, blue-green, canary) kan de rollout enkele seconden tot enkele uren duren. Na de rollout worden post-deploy tests en monitoring gestart — als de metrics normaal zijn, wordt de release als succesvol beschouwd. Automatisch terugdraaien bij overschrijding van de foutdrempel — standaardpraktijk.

Deploymentstrategieën: rolling, blue-green, canary

Rolling deploy — servers één voor één updaten. Terwijl één server wordt geüpdatet, blijven de anderen gebruikers bedienen. Na de succesvolle update van de eerste server wordt de tweede geüpdatet, enzovoort. Nadeel: tijdens de deployment draaien er verschillende versies op servers, wat incompatibiliteit kan veroorzaken. Voordeel: zero-downtime en geen behoefte aan een dubbel aantal servers.

Blue-green deploy — twee identieke omgevingen: Blue (huidige versie) en Green (nieuwe versie). Nadat Green volledig klaar en getest is, schakelt de loadbalancer het verkeer van Blue naar Green. Als er in Green een probleem wordt ontdekt — schakelen we terug naar Blue. Voordeel: onmiddellijke rollback. Nadeel: twee keer zoveel resources (servers) nodig om twee omgevingen te ondersteunen. Overschakelen duurt seconden.

Canary deploy — de nieuwe versie wordt eerst geïmplementeerd op een klein percentage servers (5–10%). Een deel van de gebruikers komt op de nieuwe versie, de rest op de oude. Als de metrics in de canary-groep normaal zijn (error rate niet gestegen, latency niet toegenomen), wordt de nieuwe versie geleidelijk uitgerold over alle servers. Google, Netflix, Spotify gebruiken canary deploy om risico's te minimaliseren. Nadeel: complexiteit van monitoring en analyse van metrics.

Automatiseringstools voor deployment

CI/CD-servers — Jenkins, GitLab CI, GitHub Actions, CircleCI, Bitrise (voor mobiel). Worden gekozen op basis van de stack: Jenkins — universeel, GitLab CI — als de repository op GitLab staat, Bitrise — voor iOS/Android. De belangrijkste taak van de CI/CD-server — het automatisch uitvoeren van de build-, test- en deployment-pipeline zonder menselijke tussenkomst.

Containerisatie — Docker, Kubernetes. Docker maakt geïsoleerde containers met de applicatie en alle afhankelijkheden. Kubernetes beheert de implementatie van containers op een cluster van servers: automatische rolling update, schaling, loadbalancing. Volgens CNCF Survey 2023 gebruikt 96% van de organisaties containers in productie, waarvan 67% Kubernetes.

Infrastructure as Code — Terraform, Ansible, Pulumi. Terraform beschrijft de infrastructuur (servers, netwerken, loadbalancers) in de vorm van code en beheert de status ervan. Ansible — serverconfiguratie: software installeren, parameters instellen. De combinatie Terraform + Ansible biedt een volledig geautomatiseerde infrastructuur: Terraform zet servers op, Ansible configureert ze. Immutable infrastructure — servers worden niet geüpdatet, maar vervangen door nieuwe met een bijgewerkte image.