CI-Gates: Was sicherst du in Azure DevSecOps Pipelines wirklich ab?

Locale-Bugs und Regressionen bei Texten tauchen spät auf, nicht in höflichen Slack-Erinnerungen. Gemeinsamer Code macht es schlimmer: ein verbotenes hartcodiertes Token im Core, eine fest auf Englisch geschriebene Prompt-Vorlage, ein fehlender Übersetzungsschlüssel, der nur in einer Locale scheitert.

Leg Sprach-Gates in CI. Native Linter in der Pipeline schlagen optionale Pre-Commit-Hooks bei gemeinsamen Repos. Die Gates sollten Prompt-Vorlagen und UI-Texte abdecken. Scheitere früh bei verbotenen hartcodierten Tokens in Core-Paketen. Halte die Liste der Gates so kurz, dass niemand sie umgeht. Regressionen bei Locales und Texten sind Produktfehler, keine Übersetzungstickets, die man hinterher anlegt.

Abbildung 1. Wiederkehrende Textfehler werden zu benannten Regeln. CI lässt den PR scheitern. Hooks können spiegeln, sie ersetzen aber nicht die Durchsetzung beim Merge, die auch für Unwillige gilt.

Kontext und Rahmenbedingung

Ein typischer Fehler: Dieselbe Klasse von Defekten rutscht durch das Review. Ein hartcodiertes Token in einem gemeinsamen Paket, ein Textschlüssel, der für eine Locale fehlt, eine Prompt-Vorlage, die von einer einzigen Sprache ausgeht. Reviewer werden es leid, menschliches grep zu spielen. grep in CI wird nicht müde.

Pre-Commit hilft willigen Entwicklern. Gemeinsame Repos brauchen eine Durchsetzung beim Merge, die auch für Unwillige gilt. Native Linter und kleine Sprachtests fangen verbotene Tokens, fehlende Schlüssel und Fehler in Vorlagen ab, bevor der Release-Zug losfährt. Folklore im Code-Review skaliert nicht über Teams hinweg.

Abbildung 2 zeigt die Einordnung aus Learn für Azure Pipelines als den Ort, an dem die Durchsetzung tatsächlich läuft.

Abbildung 2. Regressionen bei Locales und Texten sind Produktfehler. Leg die Gates in CI, wo die Durchsetzung tatsächlich läuft. Quelle: Microsoft Learn: Was ist Azure Pipelines?.

Abbildung 3 zeigt die Oberfläche für Tasks. Native Linter und kurze Sprachtests schlagen optionale Hooks, die unter Release-Druck verschwinden.

Abbildung 3. Native Linter und kurze Sprachtests schlagen optionale Hooks, die unter Release-Druck verschwinden. Quelle: Microsoft Learn: Pipeline-Tasks.

Design

1. Wiederkehrende Review-Kommentare zu Lintern machen

Wenn Reviewer immer wieder dieselbe Sauberkeit bei Texten verlangen, schreib eine Regel. Regeln sollten das verbotene Muster und die Behebung benennen. Eine Mahnung im Wiki ohne fehlschlagende Prüfung ist Dekoration.

2. CI-nativ statt optionaler Hooks

Optionaler Pre-Commit wird unter Druck übersprungen. CI bei jedem PR ist der Vertrag. Lokale Hooks können CI für mehr Tempo spiegeln, aber CI ist die Quelle der Wahrheit. "Läuft auf meinem Laptop" ist keine Sprachstrategie.

3. UI-Texte und Prompt-Vorlagen abdecken

Produkte liefern Sprache an zwei Stellen aus: in der Oberfläche und in den Prompts. Gates, die nur UI-Code prüfen, übersehen die Vorlage, die Nutzer in der falschen Sprache begrüßt. Nimm Pack-Dateien in dieselbe Richtlinie auf. Abbildung 4 zeigt diesen doppelten Geltungsbereich.

Abbildung 4. Sichere die Oberfläche und die Vorlagen ab. i18n-Prüfungen nur für die UI lassen Prompt-Packs frei, in der falschen Sprache zu begrüßen.

4. Bei verbotenen hartcodierten Tokens im Core scheitern

Varianten-Codes, Asset-Pfade und Literale für Anzeigenamen in Core-Paketen sind Grenzdefekte. Pflege eine Deny-Liste und lass den Build scheitern. Ausnahmen brauchen eine ausdrückliche Allow-Datei mit Verantwortlichen, keine Kommentare, die für immer "vorübergehend" sagen. Abbildung 5 zeigt den Vertrag an der Paketgrenze.

Abbildung 5. Der Core bleibt generisch. Varianten- und Beispiel-Packs dürfen variantenspezifische oder Demo-Sprache enthalten. Ausnahmen stehen in einer Allow-Datei mit Verantwortlichen.

5. Die Liste der Gates kurz halten

Fünf scharfe Gates schlagen zwanzig laute. Lärm erzieht zum Umgehen. Jedes Gate sollte zu einem Defekt passen, den du tatsächlich ausgeliefert hast. Schaff Gates ab, die sich nicht mehr lohnen.

6. Locale-Fehler als Produktfehler behandeln

Fehlende Schlüssel und kaputte Pluralformen blockieren das Release, wenn diese Locale zum Umfang gehört. Leg sie nicht als "Übersetzungs-Follow-ups" ab, wenn das Feature die Unterstützung bereits verspricht. Ehrlichkeit beim Umfang schlägt optimistische Häkchen.

Wie ein minimaler Satz an Gates aussieht

Fang an mit: verbotene hartcodierte Tokens im Core, erforderliche i18n-Schlüssel für geänderte Features, vorhandene Sprachmetadaten in Prompt-Vorlagen und keine rohen englischen Literale für Nutzer in markierten Paketen, wenn i18n verlangt ist. Füge Screenshot- oder Snapshot-Tests nur dort hinzu, wo sie echte Bugs fangen. Widerstehe am ersten Tag dem akademischen Unicode-Perfektionismus. Liefere die Gates, die zu deinen letzten drei Incidents passen.

Fehler handlungsfähig machen

Ein fehlschlagendes Sprach-Gate sollte die Datei, die Regel und einen einzeiligen Hinweis zur Behebung ausgeben. "Siehe Doku" ohne Pfad ist der Grund, warum Leute Prüfungen abschalten. Verlinke in der Fehlermeldung auf den Leitfaden für Vorlagen oder das i18n-README. Rufbereitschaft und PR-Autoren bekommen dieselbe Meldung. Wenn die Behebung Stammeswissen erfordert, ist das Gate nicht fertig.

Sauberkeit an Grenzen und i18n sind dieselbe Disziplin

Beide fragen, ob der Core generisch geblieben ist. Ein variantenspezifischer Text im Core ist ein Leck an der Grenze. Eine hartcodierte Annahme über die Locale ist ein Locale-Leck. Eine einzige CI-Richtlinie kann beides abdecken, wenn du die Regeln nach Paketgrenzen ordnest: Core, Varianten-Pack und Beispiel-Pack. Beispiele dürfen Demo-Sprache enthalten, der Core nicht. Sag das in den Namen der Regeln.

Häufige Fehler

Reviewer als Linter. Menschen übersehen Texte am Freitag.

Nur Hooks. Unter Druck werden lokale Werkzeuge übersprungen.

i18n-Prüfungen nur für die UI. Prompts driften ungehindert ab.

Deny-Liste ohne Verantwortliche. Ausnahmen sammeln sich still an.

Wildwuchs bei Gates. Engineers erzwingen Merges, um zu überleben.

Locales für immer im Backlog. Locales werden nur auf Folien "unterstützt".

So übernehmen oder anpassen

So übernehmen

• Sauberkeit bei Sprache und Texten wird in CI erzwungen, nicht nur durch Review-Folklore.
• CI-native Linter sind Pflicht, lokale Hooks sind optionale Spiegel.
• Die Gates decken UI-Texte und Prompt-Vorlagen in den betroffenen Paketen ab.
• Verbotene hartcodierte Tokens im Core lassen den Build scheitern, mit einem Ausnahmeprozess, der einen Verantwortlichen hat.
• Die Liste aktiver Gates bleibt kurz, dokumentiert und an echte Defekte gekoppelt.
• Fehler bei unterstützten Locales blockieren das Release und sind nicht bloß Übersetzungstickets.

Vor dem Einsatz anpassen

Gates bremsen die ersten PRs, die daran hängen bleiben, und beschleunigen jeden PR danach. Kurze Listen von Gates verlangen Produkturteil, lange Listen erzeugen eine Kultur des Umgehens. Prompts zu prüfen bringt zusätzliche Pfade, die gepflegt werden müssen. Prompts nicht zu prüfen bringt zusätzliches Release-Risiko. Deny-Listen brauchen Pflege, ohne sie verrottet ein gemeinsamer Core. Locales als Produktqualität zu behandeln kann einen Starttermin verschieben, den du nie hättest zusagen sollen.

Wichtigste Quellen: die Doku deiner Pipeline (Azure Pipelines oder GitHub Actions) und die Doku zu den i18n-Werkzeugen deines Stacks. Verbinde die Namen der Gates mit dem ADR zu den Paketgrenzen, damit Fehler auf die Architektur zeigen und nicht nur auf Texte.

Linte in CI. Deck Prompts und UI ab. Verbanne hartcodierte Tokens aus dem Core. Halte die Gates wenige und scharf. Nenn kaputte Locales, was sie sind: Produktfehler. Folklore blockiert keinen Merge. Builds schon.