Ideowy model działania głównego procesu zasad dyscypliny

Każdy zespół developerski deklaruje do jakiej wersji dyscypliny chce być zgodny. CI/CD mierzy czy ta deklaracja pokrywa się z rzeczywistością. Bramki środowiskowe egzekwują wynik — niezgodność blokuje wdrożenie lub wymaga jawnego waivera.

flowchart TD
    A(["① Zespół Deweloperski"])
    A -->|commit| B["discipline.yaml\nintencja + atestacje"]
    B -->|"Merge Request"| C

    C(["② CI/CD Pipeline"])
    C -->|include| D["discipline.yml\n deklaracja dyscypliny"]
    D --> E["Weryfikacja \n każdej normy"]
    E --> F["conformance.json\nartefakt - wynik"]

    F --> G(["③ Bramka środowiskowa"])
    G --> H{"Wszystkie checki\no wymaganym tierze\n= pass?"}

    H -->|"TAK"| OK["✅ Deploy\nna środowisko"]
    H -->|"NIE — czy jest\nważny waiver?"| W{"waiver ważny\ni nieprzeterminowany?"}
    W -->|"TAK"| WARN["⚠️ Deploy\nz jawnym długiem"]
    W -->|"NIE"| BLOCK["❌ Blokada\ndeployu"]

    style OK fill:#2d6a4f,color:#fff
    style WARN fill:#b5651d,color:#fff
    style BLOCK fill:#7b2d2d,color:#fff
    style A fill:#1a3a5c,color:#fff
    style C fill:#1a3a5c,color:#fff
    style G fill:#1a3a5c,color:#fff

① Deklaracja intencji

• Zespół commituje discipline.yaml do repozytorium. Wskazuje wersję dyscypliny, do której chce być zgodny, oraz atestuje ręcznie procesy, których CI nie może automatycznie zweryfikować (np. code review).

• Koordynator akceptuje zmiany za pomocą approve na Merge Request, który aktywuje możliwość dodania zmiany do głównego brancha.

flowchart LR
    DEV(["Zespół\ndeveloperski"]) -->|zapoznaje się z normami| PAGES["Portal\nzasady-dyscypliny\nGitLab Pages"]
    DEV -->|składa deklarację\n w repozytorium| DY["discipline.yaml"]

    style PAGES fill:#2d6a4f,color:#fff,stroke:#2d6a4f
    style DEV   fill:#2d6a4f,color:#fff,stroke:#2d6a4f
    style DY    fill:#2d6a4f,color:#fff,stroke:#2d6a4f
    linkStyle 0 stroke:#2d6a4f,stroke-width:2px
    linkStyle 1 stroke:#2d6a4f,stroke-width:2px

② Wyzwolenie pomiaru

• Każdy push lub otwarcie Merge Requestu uruchamia pipeline. Pomiar dzieje się zawsze — nie można go pominąć ani odroczyć.

• Pipeline pobiera conformance.yml ze wskazanej wersji repozytorium dyscypliny. Aplikacja nie definiuje logiki pomiarowej — jest ona centralnie zarządzana przez hub.

• Dla każdej normy z pinowanej wersji dyscypliny pipeline uruchamia bin/checks.sh. Skrypt sprawdza trzy typy weryfikacji: automatyczną (API GitLab, pliki w repo), atestacyjną (klucz w discipline.yaml) i manualną (oznaczoną explicite w normie).

• Wynik każdego checku trafia do conformance.json zapisywanego jako artefakt CI. Plik nie jest commitowany do repozytorium — jest faktem z konkretnego uruchomienia pipeline'u.

flowchart LR
    DEV(["Zespół\ndeveloperski"]) -->|inicjuje zmianę| PIPE["Centralny\nCI Pipeline"]
    PIPE -->|includes| CI_TPL["ci/conformance.yml"]
    CI_TPL -->|reads| DY["discipline.yaml"]
    CI_TPL -->|artefakt| CJ["conformance.json"]

    style DEV    fill:#b5651d,color:#fff,stroke:#b5651d
    style PIPE   fill:#b5651d,color:#fff,stroke:#b5651d
    style CI_TPL fill:#b5651d,color:#fff,stroke:#b5651d
    style DY     fill:#b5651d,color:#fff,stroke:#b5651d
    style CJ     fill:#b5651d,color:#fff,stroke:#b5651d
    linkStyle 0 stroke:#b5651d,stroke-width:2px
    linkStyle 1 stroke:#b5651d,stroke-width:2px
    linkStyle 2 stroke:#b5651d,stroke-width:2px
    linkStyle 3 stroke:#b5651d,stroke-width:2px

③ Weryfikacja przez bramkę

• Przed deployem na dane środowisko bramka odczytuje artefakt i sprawdza, czy wszystkie checki o tierze ≤ środowisko mają status pass lub są przykryte ważnym, nieprzeterminowanym waiverem.

④ Decyzja — Trzy możliwe wyniki

• ✅ Deploy — wszystkie wymagane checki przeszły.
• ⚠️ Deploy z jawnym długiem — część checków oblała, ale każda niezgodność ma ważny waiver z max-env ≥ bieżące środowisko, właścicielem i datą wygaśnięcia.
• ❌ Blokada — co najmniej jeden wymagany check oblał bez waivera lub z wygasłym waiverem. Zespół musi naprawić niezgodność albo zadeklarować jawny wyjątek.

Warning

Kluczowe rozróżnienie:

• discipline.yaml jest commitowany (intencja),
• conformance.json jest artefaktem CI (wynik).

Intencja i fakt są rozdzielone — nie można "zacommitować zgodności".

---