11. oktober 2026

Nyt nyt website!

Der er fjorten år gået siden den tidligere “Nyt website!” (se her), hvor WordPress sejrede i CMS-kampen. Det har kørt på — men et CMS med PHP-backend og database er en masse, der kan være fejl eller sårbarheder i, og det kræver vedligeholdelse, selv når intet sker.

Så i 2026 er websitet bygget op fra bunden, og den nye bund er flad: gitservice.dk er nu et statisk website, hvor en side simpelthen er en almindelig HTML-fil, som webserveren serverer. Der er ingen PHP, ingen database og ingen plugins — serveren (Apache) leverer simpelthen filen. Websitet er hurtigt, fordi der fysisk er mindre, der kan være fejl i.

Alt indhold lever som ren tekst i Git på vores egen Forgejo-server: artiklerne skrives som Markdown, og siderne som struktureret tekst i deres sprog. Astro, et webframework, der kompilerer alt til statiske filer, samler det til en færdig dist/-mappe med HTML, CSS og de JS-stykker, siderne faktisk bruger. Websitet er, som det ser ud: ingen skjulte lag, ingen overraskelser.

Udgivelsen er ligeså vigtig at bygge rigtigt som indholdet. Den nye pipeline er fire diskrete handlinger, der hver for sig kan fortrydes, så “opdatering af kode” aldrig blandes med “ændring af, hvad publikum ser”:

1. Build — type- og bygge-check af koden, og resultatet bliver verificeret i en lokal forhåndsvisning.
2. Release — et versionstag (en dato, fx v2026.10.12) skæres fra ren, verificeret main. Tagget er det, vi publicerer.
3. Deploy — det taggede commit bygges, og dist/ kopieres rullende først til den ene stack (A), så til den anden (B). Højest ét stack er uden drift ad gangen — og en afbrudt kopiering lader stacken bare servere den gamle version.
4. Cutover — én gang: begge stacks tages med i loadbalancerens pool, WordPress bliver den automatiske backup, og de sunde stacks tager trafikken af sig selv.

Reglen er kort: vi deployer aldrig det, vi ikke har relaset, og vi relaser aldrig det, vi ikke har verificeret. Og hvis det skulle gå skævt, så er løsningen simpel: det forrige tag deployes rullende igen — eller også klarer loadbalanceren det: WordPress står jo stadig i poolen som backup og tager automatisk over, hvis et stack stopper med at bestå healthchecks.

WordPress har været fint. Men det er også blevet gammelt — og næste gang den slags opstår, så skal planen ikke være “endnu et plugin”. Det skal være en ny bund, en ny pipeline, og (endnu) en ny “Nyt website!”-artikel.