Automatisch deployen naar Acceptatie en Productie met GitHub Actions

Van handmatig naar geautomatiseerd

In het begin van dit project werd elke wijziging handmatig uitgerold via de gcloud-commandoregel. Dat werkt, maar het is foutgevoelig: je bent afhankelijk van je lokale omgeving, vergeet soms een stap, en er is geen overzicht van wat er wanneer is uitgerold.

De oplossing: een volledige deployment-pipeline via GitHub Actions, gekoppeld aan GitHub Releases.

De omgevingen

Het platform draait op Google App Engine binnen één Google Cloud-project. Wij hanteren twee omgevingen:

Omgeving	App Engine service	URL
Acceptatie	acc	acc.th-ing.nl
Productie	default	www.th-ing.nl

Door met afzonderlijke App Engine services te werken, kunnen we acceptatie en productie volledig gescheiden houden — binnen hetzelfde project.

Automatisch een release aanmaken

Voor het aanmaken van releases gebruiken we Release Please van Google. Dit is een GitHub Action die op elke push naar main draait en automatisch een pull request openstelt met:

• Een opgehoogd versienummer (op basis van Conventional Commits)
• Een gegenereerd CHANGELOG.md

Zodra dat pull request wordt gemerged, maakt Release Please automatisch een GitHub Release aan met een v*-tag, zoals v1.4.0.

# .github/workflows/release.yml
on:
  push:
    branches:
      - main

jobs:
  release:
    steps:
      - uses: googleapis/release-please-action@v4
        with:
          release-type: php

Deployment naar Acceptatie

Bij elke push naar main wordt de acceptatieomgeving automatisch bijgewerkt. Dit zorgt ervoor dat de nieuwste code altijd te testen is op acc.th-ing.nl vóórdat er een officiële release plaatsvindt.

De workflow kan ook handmatig worden gestart met een specifieke branch of tag — handig voor het verifiëren van een hotfix.

# .github/workflows/deploy-acc.yml
on:
  push:
    branches:
      - main
  workflow_dispatch:
    inputs:
      ref:
        description: 'Branch of tag om te deployen'
        required: true
        default: 'main'

Deployment naar Productie

Productie wordt uitgerold op het moment dat er een v*-tag wordt gepusht — wat precies het geval is na een goedgekeurde GitHub Release. Er is bewust voor gekozen om productie niet automatisch bij elke commit bij te werken: een release is een bewuste handeling.

# .github/workflows/deploy-prod.yml
on:
  push:
    tags:
      - 'v*'
  workflow_dispatch:
    inputs:
      ref:
        description: 'Branch of tag om te deployen'
        required: true

Wat doet de deployment-workflow?

Elke deployment-workflow voert dezelfde stappen uit, ongeacht de omgeving:

1. Checkout van de juiste branch of tag
2. PHP 8.3 installeren via shivammathur/setup-php
3. Composer-dependencies installeren (met cache)
4. Assets compileren via de Symfony AssetMapper
5. Authenticeren bij Google Cloud via een service account
6. Deployen naar App Engine met gcloud app deploy

Waarom dit waardevol is

Deze aanpak heeft een paar concrete voordelen:

• Reproduceerbaarheid — iedere deployment doorloopt exact dezelfde stappen, ongeacht wie of wat de trigger is
• Overzicht — via GitHub Releases is altijd terug te zien welke versie wanneer is uitgerold en wat er in zat
• Veiligheid — productie kan nooit per ongeluk worden bijgewerkt; dat vereist altijd een expliciete release
• Snelheid — na een merge naar main is acceptatie binnen enkele minuten bijgewerkt

De initiële investering — pipeline opzetten, rechten regelen, service accounts aanmaken — heeft zichzelf al meerdere keren terugbetaald.