Har bygget GitHub Actions CI/CD‑pipelines med et distroless produktions‑frontend‑image og promovering på tværs af flere miljøer.

Situation. Levering bør ikke afhænge af, at nogen husker trinene, og det, der ender med at køre i produktion, bør ikke være en fed general‑purpose‑container, der bærer en shell og en package manager, den aldrig vil bruge — det er bare angrebsflade, der sidder der uden grund.

Opgave. Gør vejen fra commit til kørende‑i‑Azure automatisk, og hold produktions‑images så små og låst ned, som hver workload tillader.

Handling. Pipelinen er GitHub Actions. Separate workflows håndterer kodekvalitets‑gaten, testene og de miljøspecifikke deploys, med CodeQL, dependency review og et SBOM‑trin ved siden af, så intet når et miljø uden først at passere tjekkene. Images er multi‑stage‑builds, og basen for hver del blev valgt efter dens fortjeneste frem for ét blankt valg: frontenden sendes på et distroless image (gcr.io/distroless/cc‑debian13 — ingen shell, ingen package manager), Go‑API’et på en slank Alpine og database‑imaget på postgres‑slim. Promovering flytter et build gennem miljøerne ad en defineret rute frem for i hånden.

Resultat. Releases holdt op med at være et omhyggeligt manuelt ritual og blev en rutinemæssig, kedelig hændelse, hvilket er præcis, hvad man vil have fra releases. Produktions‑frontenden kører på omtrent så lidt, som man kan give den, tjekkene fanger problemer, før de lander, og “deploy” er noget, pipelinen gør, frem for noget, nogen sveder sig igennem.