Przeglądanie i scalanie zmian Bicep
Wiesz już, jak używać gałęzi funkcji 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 lekcji dowiesz się więcej na temat żądań ściągnięcia, w tym sposobu ich tworzenia i używania. Dowiesz się również, jak używać żądań ściągnięcia 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ś konserwatora o ściągnięcie zmian do głównej gałęzi repozytorium.
Żądania ściągnięcia i ochrona gałęzi
Podczas konfigurowania ochrony gałęzi można wymagać od właścicieli kodu przejrzenia żądania ściągnięcia. 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.
Żądania ściągnięcia i zasady gałęzi
Podczas konfigurowania zasad gałęzi można wymagać od określonych osób lub grupy osób przejrzenia żądania ściągnięcia. 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żde żądanie ściągnięcia było połączone z elementem roboczym. Korzystając z tej konfiguracji, można śledzić z elementu roboczego zawierającego żądanie funkcji do kodu, który implementuje zmianę, przez cały sposób wdrażania w środowisku produkcyjnym.
Tworzenie żądania ściągnięcia
Żądanie ściągnięcia można utworzyć przy użyciu interfejsu internetowego 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.
Żądanie ściągnięcia można utworzyć przy użyciu interfejsu internetowego 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 żądania ściągnięcia 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, dobra nazwa może pomóc im znaleźć żądania ściągnięcia, w których mogą przyczynić się do znaczących opinii i pominąć żądania ściągnięcia, które nie są istotne.
Ponadto nazwy żądań ściągnięcia często stają się częścią historii repozytorium Git, dlatego warto je zrozumieć, gdy ktoś patrzy wstecz na historię.
Możesz również podać opis żądań ściągnięcia. Możesz wspomnieć o konkretnych osobach lub odwołać się do problemów w opisach. Wiele zespołów tworzy standardowe szablony opisów żądań ściągnięcia, aby było jasne, czym jest 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 żądań ściągnięcia, aby było jasne, czym jest każda zmiana.
Podczas tworzenia żądania ściągnięcia możesz zaprosić osoby do przejrzenia zmian.
Czasami tworzysz żądanie ściągnięcia tylko w celu uzyskania opinii od współpracowników. W takich sytuacjach można określić, że żądanie ściągnięcia jest wersją roboczą. Recenzenci będą wiedzieć, że nadal pracujesz nad zmianami. Recenzenci nadal mogą przekazać opinię, ale jasne jest, że zmiany nie są jeszcze gotowe do scalenia. Jeśli zmiany są zadowalające, możesz usunąć stan wersji roboczej.
Nawet po utworzeniu żądania ściągnięcia możesz nadal wprowadzać zmiany w kodzie w gałęzi funkcji. Te zmiany stają się częścią żądania ściągnięcia.
Przeglądanie żądania ściągnięcia
Podczas przeglądania żądania ściągnięcia można zobaczyć wszystkie zmiany. Możesz komentować całe żądanie ściągnięcia lub po prostu 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 żądaniami ściągnięcia jest interaktywnym środowiskiem.
Podczas przeglądania kodu Bicep poszukaj następujących kluczowych elementów:
- Czy plik można wdrożyć? Wdróż i przetestuj kod Bicep przed scaleniem. 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 to żądanie ściągnięcia reprezentuje część szerszej pracy, upewnij się, że środowisko będzie działać po scaleniu i wdrożeniu tej zmiany. Jeśli na przykład żądanie ściągnięcia 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 zgodne z dobrymi praktykami Bicep? W innych modułach usługi Microsoft Learn przedstawiono elementy dobrego kodu Bicep. Upewnij się, że przeglądany kod jest zgodny z tymi samymi najlepszymi rozwiązaniami.
- Czy zmiana jest zgodna z opisem? Dobrym rozwiązaniem jest uwzględnienie opisu tytułu żądań ściągnięcia. 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 żądania ściągnięcia połączył się z elementami roboczymi lub problemami, sprawdź, czy zmiany w żądaniu ściągnięcia spełniają kryteria powodzenia zdefiniowane przez element roboczy.
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 autor żądania ściągnięcia 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 osoby zatwierdzające zakończą żądanie ściągnięcia. Twój zespół powinien zdecydować, kto scala żądania ściągnięcia i kiedy.
W niektórych zespołach autor żądania ściągnięcia 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 osoby zatwierdzające zakończą żądanie ściągnięcia. 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 żądania ściągnięcia i kiedy.
Proces twojego zespołu
Po rozpoczęciu korzystania z gałęzi funkcji i żądań ściągnięcia 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 zakończeniu wprowadzania zmian wypychają swoją gałąź lokalną do udostępnionego repozytorium.
W repozytorium udostępnionym tworzą żądanie ściągnięcia, aby scalić gałąź z gałęzią główną.
Inni członkowie zespołu przeglądają zmiany. Gdy są one spełnione, zatwierdzają żądanie ściągnięcia i są 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 wypychanie repozytorium zdalnego wyzwala zautomatyzowany potok w celu weryfikowania, 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.
