Przeglądanie i scalanie zmian Bicep
Wiesz już, jak używać gałęzi funkcjonalności i jak zastosować ochronę gałęzi, aby upewnić się, że zmiany są przeglądane przed ich scaleniem. Teraz musisz wykonać spójny proces, aby zaproponować i przejrzeć zmiany przed ich scaleniem.
W tej jednostce dowiesz się więcej na temat pull requestów, w tym jak je tworzyć i używać. Dowiesz się również, jak używać pull requestów do przeglądania kodu Bicep.
Żądania ściągnięcia
żądanie ściągnięcia to żądanie od Ciebie, deweloper funkcji, do osoby odpowiedzialnej za gałąź główną. Poproś opiekuna o włączenie twoich zmian do głównej gałęzi repozytorium.
Żądania ściągnięcia i ochrona gałęzi
Kiedy konfigurujesz ochronę gałęzi, możesz wymagać, aby właściciele kodu przejrzeli żądanie pobrania. Możesz na przykład uwzględnić potencjalnych klientów projektu jako recenzentów dla wszystkich żądań ściągnięcia lub określić, że określona liczba osób musi przejrzeć każde żądanie ściągnięcia.
Wnioski o połączenie i zasady dotyczące gałęzi
Podczas konfigurowania zasad gałęzi można wymagać od określonych osób lub grupy osób przejrzenia pull requestu. Możesz na przykład uwzględnić potencjalnych klientów projektu jako recenzentów dla wszystkich żądań ściągnięcia lub określić, że określona liczba osób musi przejrzeć każde żądanie ściągnięcia.
Możesz również wymagać, aby każdy pull request był połączony z elementem roboczym. Korzystając z tej konfiguracji, można śledzić od elementu roboczego zawierającego żądanie funkcji do kodu, który implementuje zmianę, aż do wdrożenia do środowiska produkcyjnego.
Tworzenie żądania ściągnięcia
Pull request można utworzyć za pomocą interfejsu usługi GitHub. Wybierasz gałąź źródłową, w której wprowadzono zmiany, i gałąź docelową, która jest zwykle główną gałęzią repozytorium.
Można utworzyć pull request, korzystając z interfejsu webowego usługi Azure DevOps. Wybierasz gałąź źródłową, w której wprowadzono zmiany, i gałąź docelową, która jest zwykle główną gałęzią repozytorium.
Podczas tworzenia pull requesta należy nadać mu nazwę. Dobrym rozwiązaniem jest, aby nazwy żądań ściągnięcia było jasne i zrozumiałe. Ta praktyka pomaga członkom zespołu zrozumieć kontekst tego, co są proszeni o przejrzenie. Jeśli mają różne obszary wiedzy specjalistycznej, dobra nazwa może pomóc im znaleźć pull requesty, w których mogą wnieść znaczący wkład, oraz pominąć te, które nie są istotne.
Ponadto nazwy pull requestów często stają się częścią historii repozytorium Git, dlatego warto je uczynić zrozumiałymi dla osób przeglądających historię.
Możesz również dodać opis dla żądań pull request. Możesz wspomnieć o konkretnych osobach lub odwołać się do problemów w opisach. Wiele zespołów tworzy standardowe szablony opisów żądań pobrania, aby było jasne, na czym polega każda zmiana.
Możesz również podać opis żądań ściągnięcia. Możesz wspomnieć o określonych osobach lub odwołać się do elementów roboczych w opisach. Wiele zespołów tworzy standardowe szablony opisów pull requestów, aby każdy mógł jasno zrozumieć, na czym polega każda zmiana.
Podczas tworzenia pull requesta możesz zaprosić osoby do przejrzenia zmian.
Czasami tworzysz pull request tylko w celu uzyskania opinii od współpracowników. W takich sytuacjach można określić, że pull request jest wersją roboczą . Recenzenci będą wiedzieć, że nadal pracujesz nad zmianami. Recenzenci nadal mogą wyrażać opinie, ale oczywiste jest, że zmiany nie są jeszcze gotowe do scalenia. Jeśli zmiany są zadowalające, możesz usunąć stan wersji roboczej.
Nawet po utworzeniu pull requestu, możesz nadal wprowadzać zmiany w kodzie na swojej feature branch. Te zmiany stają się częścią żądania ściągnięcia.
Przeglądanie żądania ściągnięcia
Podczas przeglądania pull requestu można zobaczyć wszystkie zmiany. Możesz komentować cały pull request lub na określonych częściach zmienionych plików. Autor żądania ściągnięcia może odpowiedzieć na komentarze, a inni recenzenci mogą uczestniczyć w dyskusjach. Te funkcje komentowania sprawiają, że współpraca nad wnioskami pull jest interaktywnym doświadczeniem.
Podczas przeglądania kodu Bicep poszukaj następujących kluczowych elementów:
- Czy plik można wdrożyć? Wdróż i przetestuj kod Bicep, zanim zostanie scalony. Upewnij się, że nie ma żadnych ostrzeżeń linter i że wdrożenie platformy Azure zakończy się pomyślnie. W przyszłym module Microsoft Learn poznasz podejścia do automatycznego wdrażania i weryfikowania zmian.
- Czy kod Bicep jest przejrzysty i zrozumiały? Ważne jest, aby wszyscy członkowie zespołu rozumieli twój kod Bicep. Podczas przeglądania pliku Bicep w żądaniu ściągnięcia upewnij się, że dokładnie rozumiesz, co dotyczy każdej zmiany. Czy zmienne i parametry są nazwane dobrze? Czy komentarze zostały użyte do wyjaśnienia złożonych sekcji kodu?
- Czy zmiana została ukończona? Jeśli ten wniosek o ściągnięcie jest częścią większego projektu, upewnij się, że twoje środowisko będzie działać po połączeniu i wdrożeniu tej zmiany. Jeśli na przykład pull request ponownie skonfiguruje zasób platformy Azure w ramach przygotowań do późniejszej zmiany, sprawdź, czy zasób nadal działa prawidłowo w całym procesie. Jeśli żądanie ściągnięcia dodaje nowy zasób platformy Azure, który nie jest jeszcze potrzebny, rozważ tymczasowe dodanie warunku, aby zasób nie został wdrożony, dopóki nie będzie potrzebny.
- Czy zmiana jest zgodna z dobrymi praktykami Bicep? W innych modułach usługi Microsoft Learn nauczyłeś się o elementach dobrego kodu Bicep. Upewnij się, że przeglądany kod jest zgodny z tymi samymi najlepszymi rozwiązaniami.
- Czy zmiana jest zgodna z opisem? Dobrym praktyką jest zawarcie opisowego tytułu w pull requestach. Wiele zespołów wymaga również, aby żądania ściągnięcia zawierały opis zmiany i jej przeznaczenie. Sprawdź, czy zmiany w kodzie Bicep są zgodne ze szczegółami żądania ściągnięcia. Jeśli autor pull requesta połączył to z zadaniami roboczymi lub problemami, sprawdź, czy zmiany w pull requeście spełniają kryteria sukcesu zdefiniowane przez zadanie robocze.
Ukończ żądanie ściągnięcia
Po zatwierdzeniu żądania ściągnięcia można go ukończyć. Oznacza to, że zawartość żądania ściągnięcia jest scalona z gałęzią główną.
W niektórych zespołach twórca pull requesta powinien również go ukończyć. Ten proces pomaga upewnić się, że autor kontroluje, kiedy odbywa się scalanie, i może być dostępny do monitorowania wszystkich zautomatyzowanych wdrożeń. W innych zespołach zatwierdzający zrealizują żądanie ściągnięcia. Twój zespół powinien zdecydować, kto scala pull requesty i kiedy.
W niektórych zespołach autor pull requestu powinien go również zakończyć. Ten proces pomaga upewnić się, że autor kontroluje, kiedy odbywa się scalanie, i może być dostępny do monitorowania wszystkich zautomatyzowanych wdrożeń. W innych zespołach osoby zatwierdzające zakończają pull request. Możesz nawet użyć usługi Azure DevOps, aby automatycznie ukończyć żądanie ściągnięcia, gdy spełnia kryteria zatwierdzania. Twój zespół powinien zdecydować, kto scala pull requesty i kiedy.
Proces twojego zespołu
Po rozpoczęciu korzystania z gałęzi funkcjonalnych i żądań ściągania, proces zespołu może zmienić się na podobny do następującego:
Członek zespołu klonuje udostępnione repozytorium.
Wprowadzają zmiany lokalne w gałęzi we własnej lokalnej kopii repozytorium.
Po wprowadzeniu zmian wypychają swoją lokalną gałąź do współdzielonego repozytorium.
W repozytorium udostępnionym tworzą pull request, aby scalić gałąź do głównej.
Inni członkowie zespołu przeglądają zmiany. Kiedy są zadowoleni, zatwierdzają żądanie ściągnięcia, które jest następnie scalane z gałęzią główną repozytorium udostępnionego.
Usuwają gałęzie w udostępnionym repozytorium i w lokalnej kopii repozytorium.
W niektórych scenariuszach przesyłanie do repozytorium zdalnego wyzwala zautomatyzowany pipeline w celu weryfikacji, testowania i wdrażania kodu. Więcej informacji na temat potoków znajdziesz w innych modułach platformy Microsoft Learn.
Na poniższym diagramie przedstawiono ten poprawiony proces.
