Omówienie zadań przepływu pracy

Ukończone

Przepływy pracy umożliwiają zautomatyzowanie kroków procesu wdrażania. Proces może obejmować kilka logicznych grup zadań, które chcesz uruchomić. W tej lekcji dowiesz się więcej o zadaniach przepływu pracy i sposobie ich używania do dodawania procesów kontroli jakości do wdrożeń Bicep.

Co to są zadania przepływu pracy?

Zadania ułatwiają podzielenie przepływu pracy na wiele bloków logicznych. Każde zadanie może zawierać co najmniej jeden krok.

Zadania mogą być używane w przepływie pracy, aby oznaczyć separację problemów. Na przykład podczas pracy z kodem Bicep walidacja kodu jest osobnym problemem przed wdrożeniem pliku Bicep. W przypadku korzystania z zautomatyzowanego przepływu pracy kompilowanie i testowanie kodu jest często nazywane ciągłą integracją . Wdrażanie kodu w zautomatyzowanym przepływie pracy jest często nazywane ciągłym wdrażaniem (CD).

W zadaniach ciągłej integracji sprawdzasz poprawność zmian wprowadzonych w kodzie. Zadania ciągłej integracji zapewniają kontrolę jakości. Można je uruchamiać bez wpływu na środowisko produkcyjne na żywo.

W wielu językach programowania należy skompilować kod, zanim ktoś będzie mógł go uruchomić. Po wdrożeniu pliku Bicep jest on konwertowany lub transpilowany z pliku Bicep do formatu JSON. Narzędzie wykonuje ten proces automatycznie. W większości sytuacji nie trzeba ręcznie kompilować kodu Bicep do szablonów JSON w przepływie pracy. Nadal używamy terminu ciągła integracja, gdy mówimy o kodzie Bicep, ponieważ inne części ciągłej integracji nadal mają zastosowanie, takie jak walidacja kodu.

Po pomyślnym uruchomieniu zadań ciągłej integracji należy zwiększyć pewność, że wprowadzone zmiany również zostaną pomyślnie wdrożone. W zadaniach ciągłego wdrażania kod jest wdrażany w każdym środowisku. Zazwyczaj rozpoczynasz od testów i innych środowisk nieprodukcyjnych, a następnie przechodzisz do środowisk produkcyjnych. W tym module wdrożymy w jednym środowisku. W przyszłym module dowiesz się, jak rozszerzyć przepływ pracy wdrażania w celu wdrożenia w wielu środowiskach, takich jak środowiska nieprodukcyjne i produkcyjne.

Zadania są uruchamiane równolegle domyślnie. Możesz kontrolować, jak i kiedy każde zadanie jest uruchamiane. Można na przykład skonfigurować zadania ciągłego wdrażania tak, aby działały dopiero po pomyślnym uruchomieniu zadań ciągłej integracji. Możesz też mieć wiele zadań ciągłej integracji, które muszą być uruchamiane w sekwencji, na przykład w celu skompilowania kodu, a następnie przetestowania go. Można również uwzględnić zadanie wycofywania, które jest uruchamiane tylko wtedy, gdy poprzednie zadania wdrażania nie powiodły się.

Przesunięcie w lewo

Za pomocą zadań można sprawdzić jakość kodu przed jego wdrożeniem. Ten proces jest czasami nazywany przesunięciem w lewo.

Rozważ oś czasu działań wykonywanych podczas pisania kodu. Oś czasu rozpoczyna się od faz planowania i projektowania. Następnie przechodzi do fazy budynku i testowania. Na koniec wdrożysz rozwiązanie, a następnie musisz je obsługiwać.

Jest to dobrze zrozumiała reguła w tworzeniu oprogramowania, którą wcześniej w procesie znajdujesz błąd — bliżej lewej strony osi czasu — łatwiejsze, szybsze i tańsze jest naprawienie. W dalszej części procesu, który wychwycisz błąd, tym trudniejsze i bardziej skomplikowane staje się naprawienie.

Dlatego celem jest przesunięcie odnajdywania problemów po lewej stronie powyższego diagramu. W tym module dowiesz się, jak dodać więcej weryfikacji i testowania do przepływu pracy w miarę postępu.

Przed rozpoczęciem wdrażania można nawet dodać walidację. Podczas pracy z narzędziami, takimi jak GitHub, żądania ściągnięcia zwykle reprezentują zmiany, które ktoś w twoim zespole chce wprowadzić do kodu w gałęzi głównej. Warto utworzyć inny przepływ pracy, który automatycznie uruchamia kroki ciągłej integracji podczas procesu przeglądu dla żądania ściągnięcia. Ta technika pomaga sprawdzić, czy kod nadal działa, nawet w przypadku proponowanych zmian. Jeśli walidacja zakończy się pomyślnie, masz pewność, że zmiana nie spowoduje problemów podczas scalania z gałęzią główną. Jeśli sprawdzanie zakończy się niepowodzeniem, wiesz, że istnieje więcej pracy do wykonania, zanim żądanie ściągnięcia będzie gotowe do scalenia. W przyszłym module dowiesz się więcej na temat konfigurowania odpowiedniego procesu wydania przy użyciu żądań ściągnięcia i strategii rozgałęziania.

Ważne

Automatyczne sprawdzanie poprawności i testy są tak skuteczne, jak testy, które piszesz. Ważne jest, aby wziąć pod uwagę kwestie, które należy przetestować, oraz czynności, które należy wykonać, aby mieć pewność, że wdrożenie jest prawidłowe.

Definiowanie zadania przepływu pracy

Każdy przepływ pracy zawiera co najmniej jedno zadanie i można zdefiniować więcej zadań zgodnie z wymaganiami. Zadania są uruchamiane równolegle domyślnie. Typ konta usługi GitHub określa liczbę zadań, które można uruchomić jednocześnie podczas korzystania z modułów uruchamianych w usłudze GitHub.

Załóżmy, że utworzono plik Bicep, który należy wdrożyć dwa razy: raz w infrastrukturze w Stany Zjednoczone i raz w infrastrukturze w Europie. Chcesz również zweryfikować kod Bicep w przepływie pracy. Oto ilustracja przepływu pracy obejmującego wiele zadań, który definiuje podobny proces:

Zwróć uwagę, że w tym przykładzie istnieją trzy zadania. Zadanie weryfikacji jest podobne do zadania ciągłej integracji. Następnie uruchomiono zadania Deploy US and Deploy Europe (Wdróż stany USA i Wdróż w Europie ). Każdy z nich wdraża kod w jednym ze środowisk. Domyślnie zadania są uruchamiane równolegle.

Poniżej przedstawiono sposób definiowania zadań w pliku YAML przepływu pracy:

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deployUS: 
    runs-on: windows-latest
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the US region."
  deployEurope: 
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the European region."

Kontrolowanie sekwencji zadań

Możesz dodać zależności między zadaniami, aby zmienić kolejność. Kontynuując poprzedni przykład, prawdopodobnie chcesz zweryfikować kod przed uruchomieniem zadań wdrażania, w następujący sposób:

Zależności między zadaniami można określić przy użyciu słowa kluczowego needs :

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deployUS: 
    runs-on: windows-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the US region."
  deployEurope: 
    runs-on: ubuntu-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the European region."

Gdy używasz słowa kluczowego needs , przepływ pracy czeka na pomyślne zakończenie zadania zależnego przed uruchomieniem następnego zadania. Jeśli przepływ pracy wykryje, że wszystkie zależności dla wielu zadań zostały spełnione, może uruchamiać te zadania równolegle.

Uwaga

W rzeczywistości zadania są uruchamiane równolegle tylko wtedy, gdy masz wystarczającą liczbę modułów uruchamianych w celu jednoczesnego uruchamiania wielu zadań. Liczba modułów uruchamianych w usłudze GitHub, których można użyć, zależy od typu posiadanego konta usługi GitHub. Jeśli potrzebujesz więcej zadań równoległych, możesz kupić inny plan konta usługi GitHub.

Czasami chcesz uruchomić zadanie, gdy poprzednie zadanie zakończy się niepowodzeniem. Oto na przykład inny przepływ pracy. Jeśli wdrożenie zakończy się niepowodzeniem, zadanie o nazwie wycofywanie zostanie uruchomione natychmiast potem:

Słowo kluczowe służy do określania if warunku, który ma zostać spełniony przed uruchomieniem zadania:

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deploy: 
    runs-on: windows-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy."
  rollback: 
    runs-on: ubuntu-latest
    needs: deploy
    if: ${{ failure() }}
    steps:
      - run: echo "Here is where you'd perform the steps to roll back a failure."

W poprzednim przykładzie, gdy wszystko pójdzie dobrze, przepływ pracy najpierw uruchamia zadanie testowe , a następnie uruchamia zadanie deploy . Pomija zadanie wycofywania. Jeśli jednak zadanie Testuj lub Wdróż zakończy się niepowodzeniem, przepływ pracy uruchamia zadanie wycofywania. Więcej informacji na temat wycofywania znajdziesz w dalszej części tego modułu.

Zadania wdrażania Bicep

Typowy przepływ pracy wdrażania Bicep zawiera kilka zadań. W miarę przechodzenia przepływu pracy przez zadania celem jest coraz bardziej pewność, że późniejsze zadania kończą się powodzeniem. Poniżej przedstawiono typowe zadania przepływu pracy wdrażania Bicep:

1. Lint: użyj lintera Bicep, aby sprawdzić, czy plik Bicep jest poprawnie sformułowany i nie zawiera żadnych oczywistych błędów.
2. Weryfikacja: użyj procesu weryfikacji wstępnej usługi Azure Resource Manager, aby sprawdzić, czy występują problemy, które mogą wystąpić podczas wdrażania.
3. Wersja zapoznawcza: użyj polecenia analizy co-jeżeli, aby zweryfikować listę zmian stosowanych w środowisku platformy Azure. Poproś człowieka o ręczne przejrzenie wyników analizy co-jeżeli i zatwierdzenie przepływu pracy w celu kontynuowania.
4. Wdrażanie: prześlij wdrożenie do usługi Resource Manager i poczekaj na zakończenie.
5. Test weryfikacyjny kompilacji: uruchom podstawowe testy po wdrożeniu względem niektórych wdrożonych ważnych zasobów. Te testy są nazywane testami weryfikacyjnymi kompilacji infrastruktury.

Twoja organizacja może mieć inną sekwencję zadań lub może być konieczne zintegrowanie wdrożeń Bicep z przepływem pracy, który wdraża inne składniki. Po zrozumieniu, jak działają zadania, możesz zaprojektować przepływ pracy zgodnie z potrzebami.

Każde zadanie jest wykonywane w nowym wystąpieniu modułu uruchamiającego, które rozpoczyna się od czystego środowiska. Dlatego w każdym zadaniu zwykle trzeba wyewidencjonować kod źródłowy jako pierwszy krok. Musisz również zalogować się do środowiska platformy Azure w każdym zadaniu, które współdziała z platformą Azure.

W tym module dowiesz się więcej o tych zadaniach i stopniowo kompilujesz przepływ pracy obejmujący poszczególne zadania. Dowiesz się również:

• Jak przepływy pracy zatrzymują proces wdrażania, jeśli coś nieoczekiwanego nastąpi w dowolnym z poprzednich zadań.
• Jak skonfigurować przepływ pracy do wstrzymania do momentu ręcznego sprawdzenia, co się stało w poprzednim zadaniu.