Rurociągi postojowe i uwolnienia

1) Dlaczego potrzebujesz rurociągu postojowego

• odtwarzalność montażu i uwalniania;
• szybkie i przewidywalne informacje zwrotne;
• zminimalizowanie ryzyka (stopniowe walcowanie, phicheflags, rollbacks);
• zgodność i zmiana kontroli.

2) Referencyjny przepływ dostaw (wysoki poziom)

1. PR → automatyczne kontrole (lint, unit, SAST, licencje).
2. Budowa → obraz/pakiet deterministyczny, podpis i SBOM.
3. Test na efemeryczne → podgląd-środowisko per-PR.

• depozycji obrazu;
• testy kontraktowe, integracyjne-, e2e;
• DAST/IAST, regresje, ładowanie dymu;
• w razie potrzeby instrukcja UAT/QA.
• 5. Zwolnij kandydata (RC) → zamrozić okno → Prod (kanaryjski/niebiesko-zielony).
• 6. Po wdrożeniu kontroli i auto-post do budżetu SLO/błędu.
• 7. Runbook/Changelog → zamknięcie wydania i retrospektywne.

3) Znormalizowany szablon rurociągu YAML (prędkość migawki)

yaml
.ci/release.pipeline.yml stages: [verify, build, test, stage, approve, release, post]

verify:
- run: make lint test:unit sbom sast sca build:
- run:
docker build -t registry/app:$GIT_SHA.
cosign sign registry/app:$GIT_SHA oras push registry/sbom:$GIT_SHA sbom.json test:
- run: make test:contract test:integration
- run: make deploy:preview && make test:e2e stage:
- run: make deploy:staging IMAGE=registry/app:$GIT_SHA
- run: make test:e2e:staging && make dast approve:
manual gate: CAB/QA lead
- type: manual required_roles: [release_manager, qa_lead]
release:
- run: make release:canary TRAFFIC=5%
- run: make release:progressive STEPS="5,25,50,100"
post:
- run: make verify:slo && make notify && make create:changelog

4) Bramy i kryteria gotowości (bramy jakości)

Kod i bezpieczeństwo: łącza, zasięg, SAST/SCA, polityka zależności, brak krytycznych/wysokie.
Umowy: zgodność systemów (API/wydarzenia), kontrola paktu/BUF.
Testy: jednostka/integracja/e2e p-threshold, stabilność (poziom płatków).
Ładunek dymu: p95/p99 w budżecie, bez degradacji.
DAST/IAST: brak krytycznych ustaleń, scenariusze testów pióra dla ścieżek wrażliwych.
Obserwacja: tablice rozdzielcze/wpisy „jako kod” zaktualizowane, załączone książki startowe.
CAB/UAT: potwierdzenie w oknach wydania (jeśli wymaga tego regulacja/biznes).

5) Strategie uwolnienia

Kanaryjski - stopniowy wzrost udziału ruchu (5% → 25% → 50% → 100%), automatyczny roll-forward/rollback dla SLO i anomalii.
Niebiesko-zielone - równoległe media; przełącznik błyskawiczny, prosty zwrot.
Flagi funkcji - logiczne włączenie funkcji bez przesunięcia; „dark launch” i zdolność A/B.
Shadow/Traffic Mirroring - ruch pasywny do nowej wersji bez wpływu na użytkowników.
Wdrażanie pierścienia - fale według regionu/najemcy.

6) Rolki i zwolnienie polityki bezpieczeństwa

Auto-rollback przez wyzwalacze: wzrost szybkości błędów, p95/TTFB powyżej progu, wzrost 5xx/timeout, skok DLQ.
Ręczny zwrot: polecenie '/rollback <service> <sha> 'w chatbot, jeden przycisk w konsoli wydania.
Zamrażanie okien: zwolnienie na wydarzenia krytyczne (turnieje/mecze szczytowe) jest zabronione.
Changelog & Release Notes: generacja z PR, SemVer tagi, komponenty, migracje.

7) Migracja i kompatybilność baz danych

1. Dodaj pola/indeksy kompatybilne

2. Wdrożenie aplikacji (odczytuje/zapisuje do obu systemów);

3. migracja danych z miejscami pracy;

4. usunąć stare.

Schematy są wersjonowane, idempotentne migracje, suchy bieg w postoju.

Chroń destrukcyjny SQL: wymagaj flagi/zatwierdzenia, automatycznych kopii zapasowych i sprawdzenia planu.

8) Ficheflags i postępująca aktywacja

Oddzielne flagi operacyjne (do bezpiecznej eksploatacji) i flagi produktów.
Włączenie przez publiczność: procent, geo, najemca, rola.
Wskaźniki flagi: uderzenie konwersji, opóźnienie, błędy.
W przypadku problemów - zwarcie flagi jest szybsze niż zwrot.

9) Obserwowalność w ramach wydania

Ślady: koniec-koniec 'trace _ id' od bramy do DB/kolejki; porównanie starych/nowych wersji.
Wskaźniki: p50/p95/p99, wskaźnik błędów, RPS, nasycenie, DLQ, retray, Time-to-Wallet/Business KPI.
Dzienniki: struktura, maskowanie PII, korelacja 'request _ id'.
Alerts: budżet SLO, pilne strony dyżuru, zwolnienie auto-convolution.

10) Bezpieczeństwo łańcucha dostaw

SBOM dla każdej budowy, przechowywania i wiązania do znacznika wydania.
Podpisy obrazów (cosign), weryfikacja na klastrze (dopuszczenie polityki).
zaświadczenie SLSA: możliwe do udowodnienia pochodzenie artefaktu.
Policy-as-Code (OPA/Conftest): odmowa domyślna dla PRS infrastruktury.
Sekrety: tylko KMS, krótkotrwałe żetony, rotacje rurociągów.

11) Zmiana kontroli i procesów

RFC → CRQ → CAB: zgadzamy się na udokumentowaną zmianę zachowania/umów z wyprzedzeniem.
Kalendarz wydania: Widoczne okna według produktu/regionu/zespołu.
Zakładki: dla każdego komponentu - procedury włączania/zwijania/diagnostyki.
Postmortem/Retro: po znaczących wydaniach - analiza i działanie.

12) Profile badań etapowych

API/Events-Blokuje niezgodne ze wspólnym rynkiem zmiany.
Integration/e2e: scenariusze typu end-to-end „deposit”, „KYC”, „withdrawal”.
Ładunek dymu: reprezentatywne szczyty; monitorujemy limity zasobów.
Scenariusze chaosu: odłączenie dostawcy, wzrost opóźnień, klapki sieciowe.
Monitorowanie syntetyczne: transakcje „próbne” w harmonogramie.

13) Makefile przykład celów uwolnienia (snippet)

makefile release: verify build test stage approve prod post verify:
@make lint test:unit sbom sast sca build:
docker build -t $(IMG).
cosign sign $(IMG)
test:
@make test:contract test:integration deploy:preview test:e2e stage:
kubectl apply -k deploy/staging approve:
@echo "Waiting for QA/CAB approval..."
prod:
make release:canary TRAFFIC="5 25 50 100"
post:
@make verify:slo notify changelog

14) Role i obowiązki

Dev/Team: jakość kodu, testy, migracje, książki startowe.
PA: scenariusze UAT/regresji, kontrola jakości bram.
SRE/Platform: niezawodność rurociągu, obserwowalność, polityka.
Menedżer wydania: kalendarz, okna, CAB, ostateczne rozwiązanie.
Bezpieczeństwo: SAST/DAST/SCA, łańcuch dostaw, tajna polityka.

15) Model zapadalności zwolnienia

1. Podstawowe - ręczne kontrole, rzadkie wydania, rolki są trudne.
2. Zaawansowany - znormalizowany CI/CD, kontur etapowy, kanaryjski/niebiesko-zielony, częste wydania.
3. Ekspert - progresywna dostawa przez najemców/regiony, funkcja flags-first, policy-as-code, SLO auto-upload, pełna identyfikowalność i SLSA.

16) Plan działania w zakresie wdrażania

M0-M1 (MVP): szablon rurociągu, budowa + znak + SBOM, rozmieszczenie, podstawowe testy i bramy.
M2-M3: kanaryjski/niebiesko-zielony, podgląd per-PR, testy kontraktowe, DAST, kontrole syntetyczne.
M4-M6: platforma flagi funkcji, ruch cieni, policy-as-code, auto-rollback, kalendarz wydania + CAB-workflow.
M6 +: rozmieszczenie pierścieni według regionu, certyfikacja SLSA i ścisłe przyjmowanie, pełna automatyzacja książek startowych.

17) Lista kontrolna przed zwolnieniem

• Obraz podpisany, SBOM załadowany i zwolniony związany.
• Umowy są zgodne, testy są zielone, e2e przekazywane na postoju.
• Migracja sprawdzona (sucha), gotowa kopia zapasowa, opisany plan zwrotu.
• Tablice rozdzielcze/wpisy zostały zaktualizowane, bramy SLO są aktywne.
• Runbook i Changelog opublikowane, wydać okna uzgodnione.
• Flagi funkcji są skonfigurowane w celu stopniowej aktywacji.
• Ograniczenia zamrożenia są spełnione, dyżur jest gotowy.

Krótki wniosek

Dobrze zaprojektowany rurociąg postojowy zamienia się w możliwą do opanowania rutynę: jednolite szablony, jasne bramy jakości, bezpieczny łańcuch dostaw, stopniowe walcowanie i obserwowalność zmniejszają ryzyko i skracają czas na zmiany produkcji, zachowując jednocześnie kontrolę nad jakością i metrykami biznesowymi.