Bijwerken bij een nieuwe versie

Dit beschrijft hoe je de omgeving bijwerkt als er updates zijn — zowel van de eigen applicaties (zgw, portal, platform) als van de onderliggende software (Open Zaak, Operaton, enz.).

Hoe versies werken

• Elke repo wordt getagd per release: v1.0.0, v1.1.0, … Productie draait altijd op een tag, niet op een losse commit, zodat je precies weet wat er draait en je kunt terugrollen.
• De image-versies van de onderliggende software (Open Zaak, Open Forms, Operaton, …) staan vastgepind in de docker-compose.yml van elke repo (bv. openzaak/open-zaak:1.x.y). Bijwerken = die pin ophogen, testen, taggen.
• platform en de twee app-repos worden onafhankelijk geversied, maar de release-notes vermelden welke combinaties samen getest zijn.

Standaard-update (de meeste gevallen)

Doe dit per repo die een update heeft. Voorbeeld voor portal; voor zgw en platform is het identiek.

cd portal
git fetch --tags
git checkout v1.1.0          # de nieuwe release-tag

# images ophalen + herstarten (data blijft in de volumes behouden)
make up                      # productie   (of: make up-local)

make up doet onder water docker compose up -d met de nieuwe images en herstart alleen de containers die veranderd zijn. Database-migraties draaien automatisch bij het opstarten: - zgw-componenten draaien hun Django-migraties in hun init-stap; - portal draait php artisan migrate --force bij het opstarten.

Volgorde bij een gecombineerde update: werk eerst zgw bij, dan portal, dan platform. Zo is de API-laag klaar voordat het portaal/ de proxy ernaar wijst. In één keer kan ook met make up-all vanuit platform nadat alle repos op de juiste tag staan.

Onderliggende software bijwerken (Open Zaak, Operaton, …)

1. Pas de image-tag aan in de docker-compose.yml van de betreffende repo.
2. Test lokaal (make up-local) — controleer de e2e-keten (formulier → object → notificatie → zaak).
3. Commit, tag een nieuwe versie, en rol uit met de standaard-update hierboven.

Lees altijd de release-notes van het component zelf: sommige upgrades vereisen een specifieke tussenversie of een eenmalige migratiecommando.

Controleren of de update goed ging

# vanuit platform/
make ps                      # alle containers 'healthy'/'running'?
make logs                    # proxy-logs (Caddy)

# per stack kun je de logs bekijken, bv.:
cd ../zgw && docker compose logs -f
cd ../portal && docker compose logs -f

Doe daarna een snelle functionele check: open portal.<domein>, log in, en dien een testformulier in om de hele keten te bevestigen.

Terugrollen

Omdat productie op tags draait en data in volumes staat:

cd portal
git checkout v1.0.0          # de vorige werkende tag
make up

⚠️ Let op met database-migraties: een teruggerolde appversie kan een nieuw databaseschema niet altijd aan. Maak daarom vóór een grote update altijd een backup (cd platform && make backup), zodat je in het uiterste geval de DB kunt terugzetten (zie back-ups.md). Kleine patch-updates zijn doorgaans probleemloos terug te rollen.

Samengevat

Situatie	Actie
Nieuwe app-release	git checkout vX.Y.Z + make up in die repo
Onderliggende software	image-tag ophogen → lokaal testen → taggen → uitrollen
Alles tegelijk	tags zetten in alle repos → make up-all (volgorde zgw→portal→platform)
Iets kapot	make backup vooraf; daarna git checkout <vorige-tag> + make up