Deploymentstrategie en omgevingsscheiding: een dev-server die omgaat met ‘wisselende meningen’

Een zin krachtiger dan welk specdocument ook: “Laat het me eerst even zien”

Als enige ontwikkelaar bij een SI-project voor de overheid was niet de techniek de grootste muur, maar ‘onzekerheid’. De ideale wereld waarin het ontwerp keurig op basis van strakke requirements tot stand komt, bestond niet. Verantwoordelijken met weinig technische kennis wisten vaak letterlijk niet wat ze wilden totdat ze het scherm met eigen ogen zagen.

“Hmm, op een plaatje kan ik het niet goed beoordelen… Kunnen we er niet echt op klikken?”

Voor elke nieuwe functie draaide ik de boel lokaal (op mijn eigen pc), maakte screenshots, zette er rode aantekeningen op en mailde een ‘rapportbestand (HWP/PPT)’. Maar met statische plaatjes kreeg je deze mensen niet tevreden.

“Oh, dat eerste was eigenlijk beter. Kun je het terugzetten?” “Wat gebeurt er als ik op deze knop druk? Maak er even een filmpje van.”

Gisteren vond men A beter, vandaag wil men B. Een eindeloze loop van lokaal aanpassen, opnieuw screenshots maken en rapporten typen. Het rapporteren duurde langer dan het ontwikkelen — totaal omgekeerde wereld.

Toen drong het echt door: ‘Niet mijn scherm screenshotten en opsturen, maar een speeltuin (een dev-server) waar de verantwoordelijke zelf naar binnen kan, op alles kan klikken en het lekker kapot kan maken.’

Een kans valt je toe: de herontdekking van een afgedankte server

Gelukkig kreeg ons team tijdens een bedrijfssplitsing onverwacht een ongebruikte server (een lege machine) toegewezen. De specs waren niet best, maar er stond Linux op en hij hing aan een publiek IP — een kostbare resource.

“Manager, mag ik die ongebruikte server hebben? Ik wil hem inrichten als een server waarop de verantwoordelijken zelf kunnen valideren.”

Ik kreeg toestemming. In deze lege bak goot ik alle technieken die ik tot dan toe geleerd had en begon ik aan ‘mijn kleine eigen infrastructuur-imperium’. Het was de optelsom van het zwoegen van de afgelopen maanden (de Works on My Machine & The Pipeline-serie).

1. GitLab (coderepository): ik installeer een private repository om de code veilig te beheren.
2. Docker Registry (image-opslag): ik richt ons eigen magazijn in voor de gebouwde Docker-images.
3. Portainer (containerbeheer): zodat ik, die de CLI eng vindt, Docker via een GUI kan beheren.
4. Nginx (webserver): ik zet een poortwachter neer die de verzoeken voor frontend en backend in goede banen leidt.

De oplossing: complete omgevingsscheiding (Dev vs Prod)

Nu had ik twee podia (Servers). Om de grillen van de verantwoordelijken te kunnen opvangen én tegelijk de productieomgeving te beschermen, splitste ik mijn deploymentstrategie.

1. Dev-server (Development): ‘het vrije laboratorium’
   • De verantwoordelijke krijgt niet eens de kans om te vragen: “Is het al klaar?”
   • Zodra er code op de develop-branch binnenkomt, draait de pipeline meteen en wordt alles automatisch gedeployed.
   • De verantwoordelijke kan op elk moment naar de URL van de dev-server gaan, de functies testen en feedback geven.
2. Productieserver (Production): ‘het gevalideerde heiligdom’
   • Er wordt alleen gedeployed wanneer de verantwoordelijke verklaart: “Deze functie is definitief!”
   • De code wordt samengevoegd in de master-branch (Merge) en pas gedeployed als ik in GitLab op de ‘deploy-goedkeuringsknop’ druk (Manual).

[Code Verification] Orde scheppen met conditional deploys

Met GitLab CI kun je per branch een ander deployment-pad opgeven. Vertaald naar code ziet die strategie er als volgt uit.

stages:
  - build
  - deploy

# 1. Build (gemeenschappelijk)
build_job:
  stage: build
  script:
    - ./gradlew build
    - docker build -t my-reg/app:$CI_COMMIT_SHA .
    - docker push my-reg/app:$CI_COMMIT_SHA

# 2. Deploy naar dev-server (automatisch)
# Zodra er code op de 'develop'-branch komt, gewoon deployen zonder vragen.
deploy_to_dev:
  stage: deploy
  script:
    - ssh user@dev-server "docker service update --image my-reg/app:$CI_COMMIT_SHA app-dev"
  only:
    - develop 

# 3. Deploy naar productie (handmatige goedkeuring)
# Ook als code op de 'master'-branch komt, wordt er pas gedeployed nadat ik op de knop druk.
deploy_to_prod:
  stage: deploy
  script:
    - ssh user@prod-server "docker service update --image my-reg/app:$CI_COMMIT_SHA app-prod"
  only:
    - master
  when: manual # Belangrijk! Het draait alleen als 'iemand op de knop drukt'.

Belangrijkste punten:

• only: - develop: de ontwikkelbranch wordt hoe dan ook automatisch gedeployed. Snelheid is hier van levensbelang.
• when: manual: voor de productiebranch bouwen we een veiligheidsmechanisme in waarbij een mens nog één keer controleert en zelf op de knop drukt.

Tot slot: ‘Alleen wonen’ is eindelijk compleet

Nu heb ook ik, als solo-ontwikkelaar, een compleet systeem in huis.

1. Lokaal (Local): functies ontwikkelen op mijn eigen computer.
2. Ontwikkeling (Dev): één git push en vijf minuten later staat het op de dev-server. De verantwoordelijke controleert het zelf.
3. Productie (Prod): alleen goedgekeurde functies bundelen en veilig met één klik deployen.

De ik van de begintijd — die met de screenshot-tool aan en aantekeningen in HWP-bestanden tot diep in de avond doorwerkte — bestaat niet meer. Als een verantwoordelijke vraagt “kun je dit nog even aanpassen?”, kan ik nu zeggen: “Komt goed, ik heb het aangepast en op de dev-server gezet, kijk maar even” en rustig mijn koffie drinken. Want het systeem doet het werk voor me.

Hiermee valt het doek voor het lange [Re: Booting]-project. Van CS-basis tot Linux, Docker en de CI/CD-pipeline. Ik hoop dat deze kennis, die ik met vallen en opstaan op kale grond heb opgebouwd, een klein baken mag zijn voor de ‘broodnodige fullstack-ontwikkelaars’ die ergens nog steeds in hun eentje aan het knokken zijn.