Zasady dyscypliny¶
W każdej organizacji istnieją standardy — branching, code review, bezpieczeństwo, jakość kodu. Zwykle żyją jako strony w wiki albo PDF-y w Confluence. Problem jest zawsze ten sam: nikt nie wie, które projekty faktycznie te standardy spełniają, a audyt jest ręczny i drogi.
Projekt Zasady dyscypliny rozwiązują to inaczej.
Standardy są wersjonowanym produktem (semver). Każda aplikacja deklaruje, do której wersji dyscypliny chce być zgodna, a CI/CD mierzy tę zgodność automatycznie przy każdym pushu. Wynik steruje bramkami wdrożeniowymi — niezgodność blokuje deployment lub wymaga jawnego, terminowego wyjątku z przypisanym właścicielem.
Nie ma miejsca na cichą niezgodność. Każdy dług techniczny jest widoczny, ograniczony w czasie i należy do konkretnej osoby.
Jak to działa?¶
System składa się z czterech procesów:
| Proces | Kto | Co |
|---|---|---|
| Wytwórczy | Zespół dyscypliny | tworzy normy, pisze skrypty weryfikujące, publikuje wersję |
| Deklaracji | Zespół developerski | zapoznaje się z normami, commituje discipline.yaml |
| Weryfikacji | CI/CD | mierzy zgodność przy każdej zmianie, produkuje conformance.json |
| Raportowania | Scheduler | zbiera artefakty ze wszystkich projektów, publikuje dashboard |
Zasoby¶
- Proces wytwórczy normy — jak tworzyć i publikować normy
- Quality Gates i deklaracja — jak działa pomiar i bramki środowiskowe
- Dashboard raportowy — jak działa agregacja i raport portfelowy
Proces wytwórczy #todo¶
- Tworzenie standardu
- Aktualizacja
- Deklaracja standardu zasad dyscypliny przez zespół developerski
Wartości merytoryczne #todo¶
- Normy — STD-PROC, STD-SEC, STD-INFRA, STD-QUAL
- Słownik — BCP 14, definicje
- Polityka wsparcia — cykl życia wersji, waivery