heygrc
Inżynieriathe heygrc team

Zatwierdzenie wciąż wygląda tak samo. Pisemna reguła już nie.

Nowy artykuł Ayouba Fandiego z GRC Engineer dotyczy zrzutów ekranu zatwierdzeń PR, które tracą na znaczeniu wraz ze wzrostem wydajności agentów. Ma rację. Kontrola, którą przepiszesz w tym kwartale, wciąż może próbkować ten zrzut ekranu, a reguła określająca, kto musi przeprowadzić przegląd, może zostać usunięta w tym samym tygodniu.

Nowy artykuł Ayouba Fandiego z GRC Engineer dotyczy kontroli zarządzania zmianami, które wciąż rejestrują zrzuty ekranu zatwierdzeń PR, podczas gdy samo zatwierdzenie traci na znaczeniu. Wydajność agentów wzrosła. Czas przeglądu nie. Zielony znak wygląda wciąż jak w 2020 roku. Tyle że to, czego dotyczy, już nie jest takie samo.

Ma rację. My dodalibyśmy jeszcze to: większość zespołów postawi na powrót człowieka do przeglądu PR. To wciąż wygeneruje ten sam zrzut ekranu. Nie określa jednak, co ta osoba musiała sprawdzić. A pisemna reguła, która określa, kto musi przeglądać rozliczenia, płatności lub cokolwiek o dużym zasięgu, może zostać zakomentowana w hotfixie, który wszyscy chętnie zmergują.

Zrzut ekranu nie rozróżnia dwóch lat

Zatwierdzenie w pull request potwierdza, że przepływ pracy osiągnął krok zatwierdzenia przed scalaniem. Zrzut ekranu nie rejestruje jednak, co recenzent sprawdził, ile uwagi poświęcił ani których pisemnych reguł przestrzegał. To wciąż główny artefakt, którego większość kontroli zarządzania zmianami oczekuje od audytora do próbkowania, ponieważ to wciąż artefakt wymieniany w definicji kontroli.

Ayoub opisuje degradację na podstawie własnych raportów inżynieryjnych: więcej wyjścia, większe PR-y, przegląd jako nowe wąskie gardło. Powołuje się na artykuł na blogu GitHub podsumowujący zewnętrzne badanie: zmiany wprowadzane przez agentów wykazywały więcej redundancji i długu technicznego, podczas gdy nastawienie recenzentów było bardziej neutralne lub pozytywne. Zrzut ekranu, który wciąż zbiera Twój katalog, nie rozróżnia tych dwóch lat. Znak jest wciąż zielony. Uwaga pod nim nie jest już taka sama.

Dodanie człowieka wciąż generuje te same dowody

Kusząca poprawka polega na odzyskaniu czasu: wymaganie udziału osoby, zmniejszenie różnicy, dodanie kolejnego zatwierdzającego. Dla niektórych zmian to słuszne rozwiązanie. To także poprawka, która nie zmienia definicji kontroli. Wciąż zbierasz zrzut ekranu zatwierdzenia. Wciąż nie zapisałeś, czego to zatwierdzenie może potwierdzać.

Pozostały czas na przegląd, jeśli go uzyskasz, poświęcany jest na pytania, które recenzja kodu już zna. Czy hotfix jest poprawny? Czy jest bezpieczny? To ważne pytania. Ale nie to: 'czy ta zmiana nie usunęła reguły, że PR dotyczący rozliczeń wymaga właściciela domeny?' Recenzent wpatrujący się w obliczenia faktur zatwierdzi edycję CODEOWNERS jako szum.

Rodzaj zmiany

Traktuj to jako ilustrację: rodzaj zmiany, który budzi pytania, a nie incydent klienta. Hotfix w reszcie PR może być czysty. Ta linia to reguła zarządzania zmianami, która staje się fałszywa.

.github/CODEOWNERS+1 -1
# domain owners/infra/ @platform-owners-/billing/ @billing-owners+# /billing/ @billing-owners  # unblocking the invoice hotfix/docs/ @docs-owners
heygrcSOC 2 CC8.1

To nie błąd ani nie luka. CC8.1 dotyczy zarządzania zmianami: zmiany muszą być autoryzowane, przeglądane i zatwierdzane zgodnie z procesem, który został zapisany. Ta linia była niezależnym przeglądem dla rozliczeń. Zakomentowanie jej oznacza, że następny PR dotyczący rozliczeń może zostać zmergowany na podstawie ogólnego zatwierdzenia. Zrzut ekranu wciąż będzie istniał. Pisemna reguła, że zmiany w rozliczeniach wymagają właściciela domeny, już nie.

Przepisz kontrolę, nie tylko zatrudnienie

Artykuł Ayouba to ostrzeżenie, by nie bronić mocniej rytuału PR tylko dlatego, że zrzut ekranu wciąż wygląda oficjalnie. Zgadzamy się. Dodatkowa porażka polega na tym, że większość zespołów w tym kwartale wciąż będzie wymagać tego zrzutu ekranu, a reguła określająca zakres przeglądu może zostać usunięta w PR, którego nikt nie traktował jako zmianę kontroli.

Jeśli przepisujesz zarządzanie zmianami pod kątem wydajności agentów, zapisz, co 'przegląd' może oznaczać, i traktuj edycje tej definicji jako objęte tą samą kontrolą. Ścieżka CODEOWNERS, wymagany sprawdzian, wyłączenie CODEOWNERS, pominięcie ochrony gałęzi: to jest kontrola. Nie są to komentarze do zadań w hotfixie.

Gdzie znajduje się heygrc

heygrc to nie newsletter, warsztat ani zamiennik dla przeglądów błędów i bezpieczeństwa, które już prowadzisz. To warstwa, która odczytuje każdy pull request w kontekście wybranych przez Ciebie ram i podanego kontekstu. Gdy zmiana utrudni obronę reguły zarządzania zmianami lub ścieżki przeglądu, sygnalizuje to na diffie. Nic nie scala. Zadaje pytanie na pull request, zanim audyt próbkuje zrzut ekranu, który już nie oznacza tego, co mówi kontrola.

Przeczytaj artykuł Ayouba. Degradacja zrzutu ekranu to jego problem. Dodatkowe pytanie dotyczy tego, co się stanie, gdy przepiszesz kontrolę i wciąż będziesz zbierać tylko zrzut ekranu.

grc-engineeringchange-managementai-agentscode-review