Omówienie weryfikacji żądania ściągnięcia
Gdy używasz żądań ściągnięcia, możesz upewnić się, że inna osoba przegląda wszelkie aktualizacje wdrożeń platformy Azure. Jednak często pomocne jest również automatyczne sprawdzanie zmian kodu. W tej lekcji dowiesz się, jak używać zautomatyzowanego sprawdzania poprawności żądania ściągnięcia i sprawdzania, aby zwiększyć zaufanie zespołu do zmian w kodzie.
Walidacja żądania ściągnięcia
Podczas przeglądania żądania ściągnięcia dla kodu Bicep może wystąpić kilka typowych kroków, które należy wykonać, aby ocenić zmianę. Te kroki mogą obejmować:
- Sprawdź, czy plik Bicep ma jakiekolwiek błędy lub ostrzeżenia linter.
- Upewnienie się, że wszystkie zasoby zdefiniowane wcześniej w pliku Bicep będą nadal działać.
- Testowanie wszystkich nowo zdefiniowanych zasobów w celu upewnienia się, że zostały one wdrożone pomyślnie i że działają zgodnie z oczekiwaniami.
Walidacja żądania ściągnięcia obejmuje automatyzację niektórych z tych działań. Podczas automatyzowania sprawdzania żądań ściągnięcia recenzenci mogą poświęcić czas na inne ważniejsze kroki przeglądu, takie jak zapewnienie, że kod spełnia standardy jakości twojego zespołu i osiąga cel biznesowy.
W przepływie pracy funkcji GitHub Actions można zdefiniować wyzwalacze, które wywołują przepływ pracy w określonych punktach procesu żądania ściągnięcia, w tym podczas tworzenia, aktualizowania, scalania lub zamykania żądania ściągnięcia.
Testowanie kodu Bicep w przepływie pracy weryfikacji żądania ściągnięcia
W poprzednich modułach przedstawiono sposób tworzenia kompleksowych przepływów pracy funkcji GitHub Actions na potrzeby tworzenia lintingu, weryfikowania, wdrażania i testowania zmian infrastruktury platformy Azure, w tym w wielu środowiskach. Te przepływy pracy są uruchamiane po scaleniu zmian z gałęzią główną.
Możesz również uruchomić wiele tych samych działań w przepływie pracy weryfikacji żądania ściągnięcia. Na przykład:
- Linting kodu Bicep pomaga upewnić się, że kod jest semantycznie poprawny i że jest zgodny z niektórymi zalecanymi praktykami Bicep punktu odniesienia.
- Walidacja wstępna pomaga zapewnić pewność, że kod zostanie pomyślnie wdrożony bez konieczności faktycznego wdrażania pliku. W zależności od typu zasobu walidacja wstępna może szukać problemów, takich jak nieprawidłowe nazwy zasobów, nieprawidłowe regiony dla określonych zasobów i czy określono konfigurację, której nie można pomyślnie wdrożyć.
- Co-jeżeli, który zawiera listę zmian, które zostaną wprowadzone w środowisku platformy Azure w wyniku wdrożenia.
- Wdrożenia w celu rzeczywistego wdrożenia zasobów i upewnij się, że nie ma żadnych błędów wdrażania.
- Testowanie zasobów po wdrożeniu w celu upewnienia się, że są one skonfigurowane zgodnie z wymaganiami biznesowymi.
Przepływ pracy weryfikacji żądania ściągnięcia jest normalnym przepływem pracy funkcji GitHub Actions, dzięki czemu może uruchamiać dowolne z tych zadań. Warto jednak zastanowić się nad typami kontroli, które warto uruchomić w żądaniu ściągnięcia. Wiele działań weryfikacji wymienionych tutaj wymaga dostępu do środowiska platformy Azure. Na przykład operacja analizy co-jeżeli porównuje zasoby zdefiniowane w plikach Bicep z zasobami w subskrypcji platformy Azure. Warto uruchomić to porównanie w środowisku produkcyjnym, ale ponieważ wprowadza to pewne dodatkowe ryzyko, może nie być wygodne uruchamianie operacji w środowisku produkcyjnym z przepływu pracy zaprojektowanego dla kodu, który nie został jeszcze ukończony lub scalony.
W tym module dodasz dwa rodzaje kontroli do przepływu pracy weryfikacji żądania ściągnięcia:
- Linting your Bicep code to run an initial set of checks on it .Linting your Bicep code to run an initial set of checks on it .Linting your Bicep code to run an initial set of checks on it .Linting
- Wdrażanie kodu w zupełnie nowym środowisku tymczasowym.
Te dwa działania nie wymagają połączenia ze środowiskiem produkcyjnym platformy Azure, a nawet z żadnym z zwykłych środowisk nieprodukcyjnych, takich jak Test, QA lub Staging. Uruchamiając te dwa działania, nadal możesz budować dużą pewność co do zmian kodu, aby można je było scalić z gałęzią główną repozytorium.
Testy są przydatne dla recenzentów, ponieważ oszczędzają czas, który w przeciwnym razie zostaną wydane ręcznie. Testy są również przydatne dla Ciebie jako autor żądania ściągnięcia, ponieważ można ich użyć do uzyskania początkowego wglądu w sposób, w jaki zmiany będą działać w dalszej części procesu wdrażania.
W własnych przepływach pracy weryfikacji żądań ściągnięcia możesz rozszerzyć kontrole poprawności przy użyciu dodatkowych działań.
Wyzwalacze cyklu życia żądania ściągnięcia
Żądanie ściągnięcia w usłudze GitHub może przechodzić przez wiele różnych zdarzeń cyklu życia. Na przykład zostanie otwarte żądanie ściągnięcia. Następnie autor może wypchnąć zmiany do gałęzi źródłowej (synchronizować), która wpływa na zawartość żądania ściągnięcia. Następnie żądanie ściągnięcia można scalić, zamknąć bez scalania, a nawet ponownie ponownie otworzyć w przyszłości.
Za pomocą funkcji GitHub Actions można zdefiniować wyzwalacze przepływu pracy, które reagują na dowolne z tych zdarzeń. Można na przykład zdefiniować przepływ pracy uruchamiany automatycznie po otwarciu, zsynchronizowaniu lub ponownym otwarciu pull_request żądania ściągnięcia, określając wyzwalacz bez dodatkowej konfiguracji:
on: pull_request
Można również określić zdarzenia żądania ściągnięcia, które wyzwalają przepływ pracy. Na przykład następujący przepływ pracy jest uruchamiany automatycznie za każdym razem, gdy żądanie ściągnięcia zostanie zamknięte:
on:
pull_request:
types: [closed]
Ważne
Jeśli w żądaniu ściągnięcia występują konflikty scalania, przepływ pracy nie zostanie uruchomiony. Należy rozwiązać konflikt i wypchnąć rozwiązanie, aby można było uruchomić przepływ pracy.
Sprawdzanie stanu żądania ściągnięcia
Wyniki przepływu pracy żądania ściągnięcia są wyświetlane na stronie szczegółów żądania ściągnięcia podczas sprawdzania. Testy umożliwiają autorom i recenzentom szybkie uzyskiwanie opinii na temat tego, czy działania automatyczne zakończyły się powodzeniem, czy niepowodzeniem, jak pokazano w poniższym przykładzie:
Domyślnie nawet jeśli sprawdzanie nie powiedzie się, żądanie ściągnięcia można scalić. Być może nie chcesz zezwalać na to, aby można było skonfigurować reguły ochrony gałęzi, aby wymusić, że określone kontrole muszą zakończyć się powodzeniem, zanim będzie można scalić żądanie ściągnięcia.
Aktualizowanie plików
Po utworzeniu żądania ściągnięcia często autor musi wprowadzać aktualizacje. Na przykład:
- Recenzent może poprosić autora o wprowadzenie zmian w kodzie.
- Jeśli automatyczne sprawdzanie nie powiedzie się, autor może zmienić kod, aby rozwiązać ten problem, a następnie zatwierdzić i wypchnąć zmiany.
Za pomocą pull_request wyzwalacza można skonfigurować przepływ pracy weryfikacji tak, aby był uruchamiany za każdym razem, gdy gałąź źródłowa jest aktualizowana. Wyniki najnowszego przebiegu przepływu pracy są wyświetlane na stronie szczegółów żądania ściągnięcia.
Przepływy pracy wielokrotnego użytku
Jeśli przyjrzysz się liście możliwych testów weryfikacji żądania ściągnięcia, zauważysz, że są to te same kroki, które będą uruchamiane w regularnym przepływie pracy wdrażania. Aby uniknąć powtórzeń, dobrym rozwiązaniem jest użycie przepływów pracy wielokrotnego użytku w usłudze GitHub.
Możesz zdefiniować przepływy pracy wielokrotnego użytku dla każdego zadania, które będą używane w różnych definicjach przepływu pracy. Zobaczysz, jak to zrobić w następnym ćwiczeniu.
Robocze żądania ściągnięcia
Jako autor zwykle otwierasz żądanie ściągnięcia, gdy wszystko będzie gotowe do przejrzenia, zatwierdzenia i scalenia zmian. Warto jednak uzyskać dostęp do automatycznych testów weryfikacji żądań ściągnięcia w trakcie pisania kodu, nawet jeśli nie jesteś jeszcze gotowy do scalenia zmian.
Po otwarciu żądania ściągnięcia w usłudze GitHub możesz oznaczyć je jako wersję roboczą. Usługa GitHub uruchamia wszystkie te same testy automatyczne, a recenzenci mogą nadal przekazywać opinie. Jeśli jednak żądanie ściągnięcia ma stan wersji roboczej, jest jasne dla wszystkich, że praca nie jest jeszcze gotowa do pełnego przeglądu i nie można jej scalić.
Szczególnie często zdarza się tworzenie roboczych żądań ściągnięcia, gdy przepływ pracy weryfikacji żądania ściągnięcia tworzy efemeryczne środowiska, ponieważ można wyświetlić podgląd zmian w aktywnym środowisku roboczym. W miarę kontynuowania wypychania zmian środowisko efemeryczne jest aktualizowane w celu uwzględnienia najnowszych zmian.