Wstęp – czyli jak zabić release jednym ustawieniem
Quality Gates brzmią świetnie na prezentacjach.
„Nie przejdzie na produkcję, jeśli nie spełnia standardów jakości.”
„Pipeline zablokuje merge, jeśli testy nie przejdą.”
„Nie pozwolimy na spadek pokrycia kodu.”
W teorii – idealnie.
W praktyce – wystarczy jeden źle ustawiony próg i cały zespół zaczyna walczyć z pipeline’em zamiast z błędami.
I wtedy Quality Gates przestają być narzędziem jakości. Stają się blokadą.
Czym w ogóle są Quality Gates?
Najprościej mówiąc – to warunki, które muszą być spełnione, żeby kod mógł iść dalej.
Na przykład:
wszystkie testy muszą przejść,
pokrycie kodu nie może spaść poniżej 80%,
nie może być krytycznych podatności bezpieczeństwa,
SonarQube nie może wykryć nowych „blockerów”.
Brzmi rozsądnie.
Problem zaczyna się wtedy, gdy zaczynamy traktować te liczby jak cel sam w sobie.
Najczęstszy błąd: liczby ważniejsze niż sens
Pokrycie kodu 90% nie oznacza dobrej jakości.
Można mieć 95% coverage i zero testów, które łapią realne błędy biznesowe.
Można mieć 60% coverage i świetnie przetestowane krytyczne ścieżki.
Jeśli Quality Gate opiera się tylko na liczbie, to zespół zaczyna optymalizować pod tę liczbę.
Efekt?
Testy pisane pod coverage.
Warunki if tylko po to, żeby się „zazieleniło”.
Sztuczne podbijanie statystyk.
A jakość? Bez zmian.
Co naprawdę powinno blokować deployment?
Tu warto zadać sobie jedno pytanie:
Co realnie stanowi ryzyko dla produktu?
Nie „co wygląda dobrze w raporcie”.
Tylko co może wyłożyć system.
Dla jednego projektu będzie to:
brak przejścia testów integracyjnych,
spadek testów kontraktowych,
krytyczna podatność bezpieczeństwa.
Dla innego – brak migracji bazy danych albo niespójność wersji API.
Quality Gate powinien chronić przed realnym ryzykiem, a nie przed spadkiem 1% coverage.
Twarde vs miękkie bramki
Nie wszystko musi być blokadą.
Można rozdzielić:
Twarde bramki (blokują merge/deploy):
nieprzechodzące testy,
błędy kompilacji,
krytyczne podatności,
brak wymaganych testów kontraktowych.
Miękkie bramki (ostrzeżenia):
niewielki spadek pokrycia,
nowe code smells,
drobne style issues.
Nie wszystko musi zatrzymywać release. Czasem wystarczy, że coś będzie widoczne i omawiane w review.
Quality Gate musi pasować do dojrzałości zespołu
Widziałem projekty, które próbowały wprowadzić pełny zestaw rygorystycznych bramek w zespole, który dopiero zaczynał pisać testy.
Efekt?
Frustracja.
Obchodzenie systemu.
Wyłączanie testów, żeby „przepchnąć”.
Jeśli zespół nie ma jeszcze stabilnych testów, to 95% coverage jako warunek merge’a to proszenie się o chaos.
Najpierw stabilność.
Potem rygor.
Quality Gates to nie kara. To informacja.
Najgorsze, co można zrobić, to traktować pipeline jak policjanta.
Jeśli Quality Gate blokuje release, zespół powinien wiedzieć dlaczego i mieć jasną ścieżkę naprawy.
Jeśli nikt nie rozumie, skąd wzięła się blokada – to znaczy, że system jest źle zaprojektowany.
Jak ustawić sensowne Quality Gates?
Kilka zasad, które w praktyce mają sens:
Blokuj tylko to, co realnie zwiększa ryzyko.
Nie ustawiaj progów „bo tak robią inni”.
Dostosuj wymagania do etapu projektu.
Regularnie przeglądaj bramki – one też powinny ewoluować.
Nie myl metryki z jakością.
I najważniejsze – Quality Gate ma pomagać zespołowi podejmować decyzje, a nie zastępować myślenie.
Podsumowanie
Quality Gates mogą realnie podnieść jakość produktu.
Ale tylko wtedy, gdy:
są dopasowane do projektu,
chronią przed prawdziwym ryzykiem,
nie opierają się wyłącznie na liczbach,
są zrozumiałe dla zespołu.
Inaczej stają się kolejną przeszkodą w pipeline.
A pipeline, który wszyscy próbują obejść, przestaje mieć sens.
