Pull request, który merge’uje się bez problemów, może nadal wpływać na to, co Twoja firma jest winna danemu frameworkowi: poszerzona rola, usunięta linijka logów, nowe miejsce, w którym lądują dane osobowe. Zadaniem Cursor Bugbot, jak podaje Cursor, jest sygnalizowanie potencjalnych błędów i problemów z jakością kodu przed merge’em. Zadaniem heygrc jest odpowiedź na inne pytanie: która kontrola jest dotknięta przez tę zmianę, z podaniem odpowiedniego punktu frameworka. Ten przewodnik to praktyczna wersja uruchomienia obu narzędzi, ponieważ żadne z nich nie zastępuje drugiego.
Do czego służy każde z nich
Utrzymuj podział obowiązków jasny dla swojego zespołu. Bugbot to recenzent kodu: poprawność, jakość, sama zmiana. heygrc to recenzent zgodności: analizuje diff w odniesieniu do wybranych frameworków (ISO 27001, SOC 2, GDPR i innych) oraz kontekstu Twojej firmy, a gdy zmiana dotyka kontroli, wskazuje, która i dlaczego, dodając komentarz recenzencki z dołączonym punktem frameworka. Nie twierdzimy, co Bugbot sygnalizuje lub pomija w przypadku danej zmiany; chodzi o to, że odpowiada na inne pytanie.
Konfiguracja obu narzędzi
Bugbot jest konfigurowany przez Cursor, zgodnie z dokumentacją Cursor. heygrc to aplikacja GitHub: zainstaluj ją z github.com/apps/heygrc na repozytoriach, które chcesz poddać recenzji (wymaga dostępu do kodu, metadanych i issue’ów oraz dostępu do zapisywania jedynie w Checkach i Pull Requestach, nigdy do kodu). Następnie skonfiguruj ją za pomocą kodu: jedno żądanie PUT do api.heygrc.com/v1/config z profilem firmy i listą frameworków, co Twój agent programistyczny może zrobić za Ciebie w około trzy minuty.
Kolejność nie ma znaczenia, a żadne narzędzie nie musi wiedzieć o istnieniu drugiego. Każde z nich publikuje własną recenzję i własny status sprawdzania na tym samym pull request.
Dostosuj częstotliwość, zanim ktoś się zdenerwuje
Dwa boty komentujące każdy push to moment, w którym zespoły zniechęcają się do całego pomysłu, dlatego zdecyduj o częstotliwości heygrc od pierwszego dnia. Obsługuje trzy tryby recenzji: auto recenzuje każdy pull request przy otwarciu, ponownym otwarciu lub pushu; auto_once recenzuje tylko przy otwarciu, nie przy każdym commicie; a mention_only pozostaje cichy, dopóki ktoś nie doda komentarza /heygrc na PR. Jeśli Twój zespół jest już przyzwyczajony do rytmu recenzenta kodu, auto_once to dobry start z niskim tarciem: jedna recenzja zgodności na PR, na żądanie później.
heygrc publikuje również jedną skonsolidowaną recenzję na każde przejście, grupując znaleziska w jednym komentarzu recenzenckim, dzięki czemu perspektywa zgodności dodaje jeden głos do wątku, a nie powódź.
Zdecyduj, co blokuje merge
Domyślnie heygrc publikuje neutralny check: informuje, a decyzja o merge pozostaje po stronie Twojego zespołu. Gdy zaufasz sygnałowi, możesz uczynić check zgodności obowiązkowym za pomocą ochrony gałęzi GitHub, tak jak w przypadku dowolnego zadania CI, dzięki czemu zmiana istotna dla kontroli wymaga jawnego potwierdzenia przez człowieka przed merge’em. Większość zespołów uruchamia tryb informacyjny przez kilka tygodni; przewodnik dotyczący uczynienia zgodności obowiązkowym checkiem przeprowadza Cię przez dokładne ustawienia.
Koszt dodania tej perspektywy
heygrc rozlicza się za recenzję, a nie za użytkownika: darmowo dla 25 recenzji prywatnych repozytoriów miesięcznie, następnie 19 USD za organizację miesięcznie z 100 recenzjami wliczonymi i 0,49 USD za każdą kolejną recenzję, przy czym repozytoria publiczne są zawsze darmowe, a 14-dniowy nieograniczony okres próbny jest dostępny po aktywacji instalacji w konsoli. Jeśli chcesz porównać to z cenami publikowanymi przez inne narzędzia recenzenckie przy Twojej skali, strona porównania kosztów przeprowadza obliczenia na podstawie opublikowanych stawek dostawców.