Cloud / Systeme
In Wie diese Website mit Prompts entstand habe ich beschrieben, wie KI bei der Migration einer alten WordPress-Seite auf eine statische Website mit AWS S3 und CloudFront half. Unterschätzt habe ich, wie schnell aus einer überschaubaren Website ein komplexes Softwareprojekt werden kann.
Wie die Komplexität entstand
Auf wenige Seiten folgten Wetterprognosen, Trainingsdaten, Spiele, Sicherheitsprüfungen, automatisierte Releases – und neun Sprachen. Wir haben Deutsch, Spanisch, Chinesisch, Französisch, brasilianisches Portugiesisch, Japanisch, Hindi und Niederländisch nach und nach ergänzt. Für die Besucher war das ein Gewinn. Für die Pipeline bedeutete jede Sprache weitere HTML-Seiten, Navigationslinks, Feeds, Metadaten und Fehlerquellen.
Unsere blauäugige Annahme: Eine statische Seite ist günstig zu bauen, also können wir jedes Mal alles neu erzeugen. Tatsächlich wartete auch eine kleine englische Änderung auf Schriftpakete, Bildgenerierung, Navigation, Übersetzungs-Builds, Sitemap und Sicherheitstests. Wir hatten neun Sprachen zu einer einzigen, unteilbaren Release-Abhängigkeit gemacht.
Alle Sprachen mussten vor der Veröffentlichung fertig sein
Das Problem waren nicht die Übersetzungen selbst, sondern unser Abhängigkeitsmodell.
Wenn Schutzmechanismen selbst Zeit kosten
Im GitHub-Verlauf finden sich Probleme mit Secret-Scannern, nicht reproduzierbaren Builds, stockenden Font-Installationen, Workflow-Konfiguration und fehlenden AWS-Berechtigungen. Bei einer Wiederherstellung wurden 534 öffentliche Objekte geprüft: 501 stimmten, 24 wichen ab und neun neue Seiten waren nicht lesbar. Jede Sicherheitsmaßnahme hatte einen Grund – zusammen erschwerten sie aber kleine Änderungen.
Mehr Automatisierung bedeutet nicht automatisch bessere Automatisierung. Ein fehlerhafter Check sollte untersucht, nicht einfach abgeschaltet werden.
Unser Umbau: Englisch zuerst, acht Sprachen danach
Die neue Architektur trennt die Hauptsprache von der nachgelagerten Übersetzungsphase.
weniger ist besser
Wichtig: Das Diagramm beschreibt die angestrebte gestaffelte Veröffentlichung, nicht einen bereits nachgewiesenen parallelen Live-Ablauf. Die Übersetzungsfreigaben werden per SHA-256 an die genaue englische Quelle gebunden. Ändert sich die englische Quelle, gelten frühere Freigaben nicht mehr. Fehlende Übersetzungen dürfen nicht stillschweigend durch englischen Text ersetzt werden.
Wir behalten reproduzierbare Builds, OIDC mit minimalen AWS-Rechten, Kostenkontrollen und keine CloudFront-Invalidierungen bei. Der englische Schritt soll nicht mehr auf acht nicht zwingend benötigte Übersetzungen warten müssen.
Was tatsächlich verifiziert wurde
Die PRs #119 bis #122 führten einen englischen Artikelcompiler, einen separaten Compiler für acht geprüfte Sprachen sowie eine Testfolge Englisch → Übersetzungen → Integritätsprüfung ein. Der Testworkflow verfügt über keine AWS-Schreibrechte. Die separate gestaffelte Veröffentlichung ist zunächst durch Freigabevariablen gesperrt. Der bestehende automatische OIDC-Release-Workflow führt weiterhin die vollständigen Website-Tests aus.
Ein grüner CI-Check beweist nicht, dass Englisch bereits auf S3 liegt, während die Übersetzungen noch verarbeitet werden. Frühere Shadow-Logs meldeten ausdrücklich sourceToHtmlBuildComplete=false, productionDeploymentApproved=false und null S3-Schreibvorgänge.
Gemessene Zeitverbesserungen
Bei zwei vergleichbaren neunsprachigen Changelog-Änderungen am 7. November 2026 ergaben sich folgende Werte. Es sind Messungen der bestehenden Gesamtpipeline, nicht zwei vergleichbare gestaffelte Produktiv-Releases.
| Messgröße | Vorher | Nachher | Veränderung |
|---|---|---|---|
| Offline-CI | 3:38 min (218 s) | 3:18 min (198 s) | 9,2 % schneller |
| Vollständiger Qualitätscheck | 2:55 min (175 s) | 2:27 min (147 s) | 16,0 % schneller |
| Gitleaks | 56 s | 67 s | 11 s langsamer |
| Semgrep | 10 s | 11 s | nahezu gleich |
| pip-audit | 13 s | 12 s | nahezu gleich |
| PR eröffnet bis Merge | 41:50 min | 34:29 min | 7:21 min kürzer |
weniger ist besser
Der vollständige Qualitätscheck ist Teil der Offline-CI-Zeit; die Werte dürfen nicht addiert werden. Die Security-Jobs laufen parallel. Bei Semgrep und pip-audit waren die aufwendigen Scan-Schritte wegen der Art der Änderungen übersprungen worden. Zwei Runs belegen noch keinen dauerhaften Trend.
Weitere Optimierungen: identische Assets nur einmal prüfen, SHA-256-Hashes für Navigation und Sprachseiten wiederverwenden, Caching für Python und Sharp, Messung einzelner Generatoren sowie eine schnelle Route für reine Dokumentationsänderungen.
Die neue englische Fast Lane
Ein separater Shadow-Benchmark benötigte 0,562 Sekunden für den englischen HTML-Vertrag (60 Seiten, 96 Assets, 514 interne HTML-Links). Die simulierte englische Merge-Prüfung dauerte 15 Sekunden. Bei der Isolationsprüfung blieben 501 Dateien der anderen Sprachen unverändert.
Das sind Komponenten- und Testwerte – kein legitimer Vergleich von 15 Sekunden mit 198 Sekunden für einen vollständigen Release. Gerade diese Unterscheidung ist wichtig.
Vom Pull Request zur Live-Seite
Ein Pull Request ist kein Deployment. Erst nach Review, erfolgreicher CI und Merge prüft der Release-Prozess die tatsächlichen Dateien, SHA-256-Manifeste, AWS-Berechtigungen und das Kostenbudget. Danach kann er gezielt nach S3 hochladen. CloudFront aktualisiert sich ohne kostenpflichtige Invalidierungen über seine normale TTL.
Für einen echten Nachweis der gestaffelten Veröffentlichung messen wir: T0 englischer Merge, T1 englische Prüfungen, T2 bestätigter englischer S3-Upload, T3 Beginn und Ende der Übersetzungsphase und T4 bestätigter Upload der acht Sprachen. Nur solche Belege zeigen, ob Englisch wirklich früher für Leser verfügbar wird.
KI als Partner beim Debuggen
Ein nützlicher Ablauf: ChatGPT untersucht fehlgeschlagene PR-Checks, liest Logs, schlägt kleine Korrekturen vor und prüft die nächste CI-Ausführung. Gerade abends spart das wiederholte manuelle Nachsehen. Das ist aber keine Zusage, dass eine Chat-Sitzung unbegrenzt unbeaufsichtigt weiterarbeitet. Die endgültige Prüfung und Merge-Entscheidung bleiben nachvollziehbar.
Fazit
Unsere eigentliche Optimierung besteht nicht nur aus einigen Sekunden weniger Rechenzeit. Wir haben verstanden, dass das erste nützliche Ergebnis nicht von jedem optionalen Folgeergebnis abhängen darf. Englisch soll früh zuverlässig erscheinen; die anderen acht Sprachen folgen mit derselben Qualität, aber getrennten Freigaben.
Die nächsten realen Deployments müssen zeigen, wie groß dieser Zeitvorteil unter Produktionsbedingungen tatsächlich ist.