Jeśli pracujesz z Gitem, prawdopodobnie używasz Git Flow lub innego typu workflow, który zakłada, że kod gałęzi „main” jest gotowy do wdrożenia produkcyjnego. Oznacza to, że każdy Pull Request kierowany do tej gałęzi powinien zostać zweryfikowany i przetestowany. Właśnie tutaj sprawdzają się polityki gałęzi Azure DevOps.
W artykule omówimy ustawienia, które pomogą nam utrzymać wysoką jakość kodu, przyspieszyć przegląd PR i zminimalizować problemy po wdrożeniu.
Ten kompleksowy poradnik obejmuje:
- Zrozumienie polityk dla wszystkich repozytoriów vs. pojedynczego repozytorium.
- Konfigurowanie minimalnych wymagań dotyczących recenzentów i kontroli jakości kodu.
- Konfigurowanie walidacji budowania.
- Implementowanie kontroli bezpieczeństwa i walidacji statusu.
- Najlepsze praktyki dla zespołów o różnej wielkości.
- Szybkie konfiguracje do natychmiastowego wdrożenia.
Polityki dla wszystkich repozytoriów vs. polityki dla pojedynczego repozytorium
Zacznijmy od krótkiego wyjaśnienia tych dwóch typów.
Polityki dla wszystkich repozytoriów będą stosowane do wszystkich repozytoriów w projekcie, jak sama nazwa sugeruje. Możesz je zastosować do gałęzi domyślnej (main/master) lub dowolnej innej gałęzi, która pasuje do określonego wzorca. Jest to naprawdę przydatne w przypadku ustawień takich jak minimalna liczba recenzentów lub kontrole bezpieczeństwa (więcej na ten temat później).
Zasady te znajdziesz w Settings > Repositories > Policies > [default branch]
Polityki dla pojedynczego repozytorium stosują się tylko do konkretnego repozytorium. Możesz znaleźć te polityki, przechodząc do Settings > Repositories > [Twoje repozytorium] > Policies > [Twój branch]
Ważne: Polityki dla pojedynczego repozytorium są addytywne w stosunku do polityk dla wszystkich repozytoriów. Jeśli ustanowisz politykę dla wszystkich repozytoriów, zostanie ona zastosowana na poziomie repozytorium, ale możesz dodać bardziej restrykcyjne polityki w razie potrzeby.
Przegląd polityk gałęzi
Azure DevOps oferuje kilka typów polityk gałęzi. Zbadajmy najczęściej używane.
Wymagaj minimalnej liczby recenzentów
Zawsze powinieneś mieć kogoś, kto sprawdzi Twój kod. Nie tylko prowadzi to do zwiększonego bezpieczeństwa i lepszej jakości kodu w PR, ale informacja zwrotna pomoże Ci rozwijać się jako inżynierowi oprogramowania w miarę upływu czasu.
Dlatego zawsze dążymy do co najmniej 1 recenzenta, który nie jest autorem lub współautorem PR (dwa górne pola wyboru).
Jeśli zostaną wypchnięte nowe zmiany, wszystkie głosy zatwierdzenia powinny zostać zresetowane. Zapewnia to, że żadne przypadkowe zmiany nie zostaną zatwierdzone w gałęzi głównej.
Sprawdź rozwiązanie komentarzy
Ta polityka zapewnia, że wszystkie komentarze w pull request są rozwiązane przed zakończeniem.
Dlaczego to ważne: Zapobiega zakończeniu niekompletnych dyskusji do gałęzi głównej i pomaga utrzymać przejrzystość kodu. Jeśli recenzent zadaje pytanie lub sugeruje poprawki, polityka zapewnia, że są one zaadresowane przed ukończeniem PR.
Ogranicz typy scalania
Typy scalania niekoniecznie są czymś, co chcemy ograniczyć w projekcie. Zależy to od naszego przepływu pracy i preferencji.
Jednak w większości przypadków uważam, że „squash merge” to dobra opcja. Eliminuje wszystkie niepotrzebne commity, takie jak „literówka w zmiennej”, co pomaga utrzymać czystą i przejrzystą historię gałęzi głównej.
Sprawdź połączone elementy pracy
Ta polityka wymaga, aby pull requesty miały połączone elementy pracy, co poprawia możliwość śledzenia i zarządzania projektami.
Dlaczego to ważne: Każda zmiana kodu powinna odpowiadać wymaganiu biznesowemu, historii użytkownika lub zgłoszonemu błędowi. Ta polityka zapewnia:
- Kompletną ścieżkę audytu tego, co się zmieniło i dlaczego.
- Lepsze śledzenie do celów zgodności i zarządzania.
- Ulepszone planowanie i retrospektywy sprintów.
- Łatwiejsze identyfikowanie powiązanych zmian w całej bazie kodu.
Deweloperzy po prostu łączą elementy pracy podczas tworzenia lub aktualizowania PR. Można to zrobić w interfejsie PR lub po prostu wpisując #ID w opisie PR lub w wiadomościach commitów.
Walidacja budowania
Walidacja budowania zapewnia, że kod buduje się pomyślnie i przechodzi testy przed scaleniem. To jedna z najważniejszych polityk do utrzymania jakości kodu.
Zrozumienie etapów potoku budowania
Twój potok CI/CD zwykle składa się z wielu etapów:
- Etap budowania: buduje kod i tworzy artefakty.
- Etap testów: Uruchamia testy jednostkowe, testy integracyjne i analizę pokrycia kodu.
- Etap wdrożenia: Wdraża w środowiska testowe/staging dla dodatkowej walidacji.
Etap budowania powinien zawsze działać przy użyciu konfiguracji Release/Publish. To przyspiesza proces przeglądu, natychmiast pokazując nam błędy kompilacji.
Etap testów powinien zawsze zakończyć się ze 100% wskaźnikiem sukcesu. Zapewnia to, że PR nie wprowadza nowych błędów ani nie psuje istniejących funkcjonalności.
Etap wdrożenia jest często pomijany w walidacji PR, ale jest naprawdę pomocny, aby QA miało na żywo podgląd zmian. Ponadto jest to konieczne do walidacji wdrożenia, jeśli używasz podejścia infrastructure-as-code (IaC) (szablony ARM, Terraform, pliki Bicep itp.). Wtedy po każdej zmianie w repozytorium należy sprawdzić, czy wszystko działa jak należy.
Konfiguracja walidacji budowania
Aby skonfigurować walidację budowania, po prostu wybierz swój potok. Wynik powinien wygasnąć za każdym razem, gdy zmieni się chroniona gałąź. Powinien również automatycznie uruchomić się ponownie za każdym razem, gdy zostaną wypchnięte nowe zmiany w PR. Zapewnia to, że wszystkie wyniki są aktualne.
Rekomendacja: Możesz używać tego samego potoku do ręcznych wdrożeń i wyzwalanych przez PR. Jeśli potrzebujesz nieznacznie zmienić jego zachowanie, możesz użyć prostego warunku:
${{ if eq(variables['Build.Reason'], 'PullRequest') }}
Kontrole statusu
Kontrole statusu walidują status wysyłany przez usługi zewnętrzne. Są one często używane do:
- dedykowanych bramek jakości kodu,
- usług skanowania bezpieczeństwa,
- testów integracyjnych z systemów zewnętrznych.
Są one często wyzwalane z potoku, ale wyniki są publikowane osobno. Pomagają utrzymać wysoką jakość kodu i przyspieszyć proces przeglądu.Konfiguracja: Połącz się z zewnętrznymi punktami końcowymi kontroli statusu, które raportują status powodzenia/niepowodzenia dla Twojego PR.
Najlepsza praktyka bezpieczeństwa: Detekcja wycieków tajnych wpisów
Dla mniejszych projektów rekomenduje się co najmniej użycie narzędzi do detekcji wycieków tajnych wpisów, takich jak Gitleaks. Można go szybko skonfigurować w potoku budowania lub dedykowanym potoku bezpieczeństwa. Ten mały krok pomoże nam szybko złapać przypadkowe ujawnienie haseł lub kluczy API.
Automatycznie dołączeni recenzenci
To ustawienie jest jednym z ulubionych wśród deweloperów. Dzięki niemu możesz automatycznie dodawać recenzentów do Twojego PR, co oznacza, że wszyscy otrzymają powiadomienie, gdy tylko utworzysz nowy PR. Możesz określić konkretnych ludzi lub pójść o krok dalej i określić zespół Azure DevOps, który będzie dodany jako recenzent.
Do zespołu możesz dołączyć wszystkich deweloperów lub skonfigurować dedykowany zespół review/QA, który będzie dołączony jako wymagany recenzent we wszystkich repozytoriach. Wszyscy oni otrzymają powiadomienie, ale wystarczy, że tylko 1 z nich zatwierdzi PR, aby polityka została spełniona.
Rekomendacje szybkiego startu
Na podstawie rozmiaru zespołu i złożoności projektu możesz użyć następujących konfiguracji polityk gałęzi.
Dla małych projektów
- Wymagaj minimalnie 1 recenzenta (nie autor/współautor).
- Sprawdź rozwiązanie komentarzy.
- Walidacja budowania (etapy budowania + testów).
- Sprawdź ujawnienie tajnych wpisów.
- Sprawdź połączone elementy pracy (opcjonalne; używaj jeśli adoptujesz Agile/Scrum).
Uzasadnienie: Lekkie wymagania, dbające jednocześnie o jakość kodu i proces recenzji.
Dla dużych projektów enterprise
- Wymagaj minimalnie 2-3 recenzentów (w tym architekta/lidera technicznego).
- Sprawdź rozwiązanie komentarzy.
- Walidacja budowania (etapy budowania + testów + wdrożenia).
- Sprawdź połączone elementy pracy.
- Ogranicz typy scalania tylko do squash merge.
- Kontrole statusu (skanowanie bezpieczeństwa, bramki jakości kodu).
- Używaj polityk dla wszystkich repozytoriów dla spójności w organizacji.
Uzasadnienie: Bardziej restrykcyjne kontrole zapewniają jakość, bezpieczeństwo i zgodność w dużych bazach kodu i zespołach.
Sii x Microsoft
Jako partner Microsoft Cloud oferujemy rozwiązania, które optymalizują procesy, usprawniają współpracę i umożliwiają osiągnięcie zwinności biznesowej z wykorzystaniem AI.
Oferta MicrosoftPodsumowanie najlepszych praktyk
- Zacznij konserwatywnie: Zacznij od niezbędnych polityk (recenzenci + walidacja budowania) i dodawaj więcej w miarę postępów.
- Udokumentuj swoje polityki: Komunikuj zespołowi, dlaczego każda polityka istnieje.
- Regularnie monitoruj: Okresowo oceniaj, czy polityki są zbyt restrykcyjne czy zbyt liberalne.
- Automatyzuj, co możesz: Używaj kontroli statusu do skanowania bezpieczeństwa i narzędzi jakości kodu.
- Zezwól na wyjątki: Niektórzy użytkownicy mogą potrzebować uprawnień do ominięcia polityk w przypadku awaryjnych poprawek.
- Stopniowe egzekwowanie: Zacznij od polityk jako „opcjonalne” ostrzeżenia, zanim staną się „wymagane”.
Zakończenie
Polityki gałęzi mogą ułatwić nam życie. Pomagają nam utrzymać wysoką jakość kodu i zmniejszyć problemy z wdrożeniem w Azure DevOps. Poprzez zrozumienie różnych polityk i konfigurację ich odpowiednio do wielkości zespołu i potrzeb projektu, możesz znacznie ulepszyć swój przepływ pracy.
Kluczem jest znalezienie właściwej równowagi: polityki powinny być wystarczająco restrykcyjne, aby wyłapać problemy na wczesnym etapie, ale nie na tyle restrykcyjne, aby deweloperzy je omijali i byli sfrustrowani.
Aby uzyskać więcej informacji, zapoznaj się z dokumentacją.
Zostaw komentarz