169 lines
3.0 KiB
Markdown
169 lines
3.0 KiB
Markdown
# 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 check`
|
||
- `make test`
|
||
- `make lint`
|
||
|
||
Die CI ruft diese Targets lediglich auf.
|
||
|
||
---
|
||
|
||
## Mindest‑Stages (verpflichtend)
|
||
|
||
Jede Pipeline besteht mindestens aus folgenden Stages:
|
||
|
||
1. **Preflight / Validation**
|
||
2. **Lint / Static Checks**
|
||
3. **Tests**
|
||
4. **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.example` vollstä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.
|