3.0 KiB
CI_POLICY.md
Zweck
Diese CI‑Policy definiert verbindliche Regeln für Continuous Integration in allen Projekten, die den wlkns‑Standards folgen.
CI ist hier kein Komfort‑Feature, sondern ein Qualitäts‑ und Sicherheits‑Gate.
Wenn die CI rot ist, ist das Ergebnis nicht auslieferbar. Diskussion zwecklos.
Grundhaltung
- CI ersetzt kein Denken
- CI erzwingt Mindestqualität
- CI ist reproduzierbar
- CI ist deterministisch
Eine Pipeline darf nichts tun, was lokal nicht ebenfalls prüfbar ist.
Single Source of Truth
Die fachliche Prüflogik liegt nicht in der CI‑Pipeline selbst.
Regel:
Alles, was die CI prüft, muss lokal über definierte Befehle prüfbar sein.
Bevorzugt:
make checkmake testmake lint
Die CI ruft diese Targets lediglich auf.
Mindest‑Stages (verpflichtend)
Jede Pipeline besteht mindestens aus folgenden Stages:
- Preflight / Validation
- Lint / Static Checks
- Tests
- Build
Optional (projektspezifisch):
- Security‑Scans
- Image‑Scans
- Deployment
Stage 1 – Preflight
Ziel:
- Validierung der Projektstruktur
- Prüfung der Voraussetzungen
Typische Checks:
- benötigte Dateien vorhanden
.env.examplevollständig- keine Secrets im Repository
- Tool‑Versionen kompatibel
Fehlschlag ⇒ sofortiger Abbruch.
Stage 2 – Lint / Static Checks
Ziel:
- einheitlicher Stil
- frühe Fehlererkennung
Regeln:
- Linter sind Pflicht
- Projekt‑spezifische Regeln sind erlaubt
- Warnungen dürfen nicht ignoriert werden
Ein Projekt ohne Linter gilt als unvollständig.
Stage 3 – Tests
Ziel:
- funktionale Korrektheit
- Schutz vor Regressionen
Regeln:
- automatisiert
- reproduzierbar
- ohne Seiteneffekte
Keine Tests bedeutet:
- kein Merge
- kein Release
Stage 4 – Build
Ziel:
- verifizierbare Artefakte
Regeln:
- Build muss lokal reproduzierbar sein
- bei Containern: Image baubar
- kein Push bei Fehlschlag
Ein erfolgreicher Build bestätigt technische Lieferfähigkeit.
Merge‑ & Release‑Regeln
- Merges nur bei grüner Pipeline
- Releases nur aus validierten Commits
- kein Bypass der CI
Regel:
Ein Commit ohne grüne CI existiert nicht.
Tool‑Neutralität
Diese Policy ist bewusst CI‑System‑agnostisch.
Unterstützte Umgebungen (Beispiele):
- GitHub Actions
- Gitea Actions
- GitLab CI
Die Regeln bleiben identisch – nur die Syntax ändert sich.
Verhältnis zu SOPs
Diese CI‑Policy ergänzt die bestehenden SOPs.
Beispiel:
- Container‑SOP definiert
make check - CI ruft exakt dieses Target auf
Keine doppelte Logik. Keine Abweichungen.
Anti‑Patterns
- CI mit Projekt‑spezifischer Logik
- Checks nur in der CI, nicht lokal
- manuelles Überspringen von Stages
- „temporär deaktivierte“ Tests
Wenn die CI im Weg ist, ist das Problem nicht die CI.
Status
Version: v1.0 (Baseline)
Änderungen an dieser Policy sind selten, bewusst und versioniert vorzunehmen.