Bramka jakości (quality gate) to zestaw warunków, które musi spełnić nowy kod projektu PlusWorkflow, żeby analiza na serwerze dostała status „Passed”. Projekt używa bramki „Suncode way”. Bramka ocenia tylko nowy kod, więc dług techniczny w starszym kodzie jej nie blokuje — każda zmiana ma jednak spełniać progi.
Warunki
| Warunek | Metryka w Sonarze | Próg | Wartość 14.11.2026 | Stan 14.11.2026 | Co mierzy |
|---|---|---|---|---|---|
| Pokrycie testami nowego kodu | new_coverage | co najmniej 40% | 32,9% | Niespełniony | Jaki procent linii i warunków w nowym kodzie wykonują testy jednostkowe. |
| Zduplikowane linie w nowym kodzie | new_duplicated_lines_density | najwyżej 3% | 1,7% | Spełniony | Jaki procent nowych linii jest kopią innego fragmentu kodu. |
| Przejrzane hotspoty bezpieczeństwa | new_security_hotspots_reviewed | 100% | brak hotspotów | Spełniony | Hotspot to miejsce wrażliwe pod względem bezpieczeństwa, które wymaga oceny człowieka (nie musi być błędem). Każdy w nowym kodzie musi mieć status Safe lub Fixed. |
| Ocena niezawodności | new_software_quality_reliability_rating | A | D | Niespełniony | Wynika z najpoważniejszego otwartego zgłoszenia wpływającego na niezawodność (błędy działania). |
| Ocena bezpieczeństwa | new_software_quality_security_rating | A | C | Niespełniony | Wynika z najpoważniejszego otwartego zgłoszenia wpływającego na bezpieczeństwo (podatności). |
| Ocena utrzymywalności | new_software_quality_maintainability_rating | A | A | Spełniony | Wynika z długu technicznego nowego kodu względem jego rozmiaru. |
Wszystkie warunki muszą być spełnione jednocześnie. Aktualne wartości są na stronie projektu w Sonarze; tabela pokazuje stan z dnia przygotowania tej strony.
Oceny A–E
Oceny niezawodności i bezpieczeństwa zależą od wagi najpoważniejszego otwartego zgłoszenia w nowym kodzie:
| Ocena | Najpoważniejsze otwarte zgłoszenie |
|---|---|
| A | brak zgłoszeń albo tylko o wadze Info |
| B | Low |
| C | Medium |
| D | High |
| E | Blocker |
Próg „A” oznacza, że jedno otwarte zgłoszenie o wadze Low w nowym kodzie wystarcza, żeby bramka nie przeszła. Zgłoszenia oznaczone jako False Positive albo Accepted nie liczą się do oceny (strona SonarQube - fałszywe alarmy i oznaczanie zgłoszeń). Ocena utrzymywalności liczy się inaczej: jako stosunek szacowanego czasu naprawy długu technicznego do szacowanego czasu napisania nowego kodu (A to najwyżej 5%).
Czym jest nowy kod
Nowy kod to linie dodane lub zmienione od analizy bazowej z 16.10.2026. Serwer ma tak ustawiony okres nowego kodu dla gałęzi main (tryb „konkretna analiza”, ustawiony ręcznie 14.11.2026). Wszystko, co zmieniło się w kodzie od tej daty, liczy się do bramki — także linie tylko przeformatowane albo przeniesione, np. przy migracji JSP ze Struts na Spring.
Okres nowego kodu ustawia administrator Sonara. Gdy zostanie przesunięty (np. przy wydaniu wersji), zgłoszenia ze starszych zmian przestają liczyć się do bramki.
Jak nie psuć bramki
- Zgłoszenia: poprawiaj uwagi wtyczki w IDE i asystenta AI na zmienionych liniach przed MR-em (SonarQube - Connected Mode w IntelliJ, SonarQube - praca z asystentem AI). Każde zgłoszenie wpływające na niezawodność lub bezpieczeństwo obniża ocenę poniżej A.
- Pokrycie: pisz testy jednostkowe do nowej logiki. Próg 40% dotyczy całego nowego kodu w okresie, więc kod bez testów obniża wynik całego zespołu.
- Duplikacja: nie kopiuj większych fragmentów kodu; wydziel wspólną część.
- Fałszywe alarmy: oznaczaj je na serwerze z uzasadnieniem po scaleniu, nie ukrywaj w kodzie.