Projektowanie strategii przepływu pracy i przechowywania wersji

Ukończone

Gdy zaczniesz publikować kod Bicep wielokrotnego użytku, prawdopodobnie używasz podejścia ręcznego. Łatwo jest określić, który plik Bicep należy opublikować, i prawdopodobnie masz proces ręczny w celu przyrostowania numeru wersji.

Podczas automatyzowania procesu publikowania należy wziąć pod uwagę sposób automatyzacji tych kroków. W tej lekcji dowiesz się, jak wdrożyć system przechowywania wersji, który komunikuje zmiany wprowadzone w kodzie. Dowiesz się również, jak ograniczyć zakres przepływów pracy, aby opublikować tylko oczekiwany kod.

Numery wersji

W poprzednich modułach szkoleniowych usługi Microsoft Learn przedstawiono znaczenie przechowywania wersji dla specyfikacji szablonu i modułów Bicep. Możesz wybrać jedną z wielu różnych metod przechowywania wersji. W wielu sytuacjach dobrym rozwiązaniem jest użycie wieloczęściowego systemu przechowywania wersji. System obsługi wersji wieloczęściowych składa się z wersji głównej , wersji pomocniczej i numeru poprawki , podobnie jak w poniższym przykładzie:

W poprzednim przykładzie wersja główna to 1, wersja pomocnicza to 4, a numer poprawki to 106.

Zmiany w różnych częściach numerów wersji komunikują ważne informacje o typach zmian w kodzie:

• Za każdym razem, gdy wprowadzisz zmianę powodującą niezgodność, należy zwiększyć numer wersji głównej. Załóżmy na przykład, że dodasz nowy obowiązkowy parametr lub usuniesz parametr z pliku Bicep. Są to przykłady zmian powodujących niezgodność, ponieważ Bicep wymaga określenia obowiązkowych parametrów w czasie wdrażania i nie zezwala na ustawianie wartości dla nieistniejących parametrów. Dlatego należy zaktualizować numer wersji głównej.

• Za każdym razem, gdy dodasz coś nowego do kodu, ale nie jest to zmiana powodująca niezgodność, należy zwiększyć numer wersji pomocniczej. Załóżmy na przykład, że dodasz nowy opcjonalny parametr z wartością domyślną. Opcjonalne parametry nie są zmianami powodujących niezgodność, dlatego należy zaktualizować numer wersji pomocniczej.

• Za każdym razem, gdy wprowadzisz poprawki błędów zgodne z poprzednimi wersjami lub inne zmiany, które nie wpływają na sposób działania kodu, należy zwiększyć numer poprawki. Załóżmy na przykład, że refaktoryzujesz kod Bicep, aby lepiej wykorzystać zmienne i wyrażenia. Jeśli refaktoryzacja w ogóle nie zmienia zachowania kodu Bicep, zaktualizuj numer poprawki.

• Przepływ pracy może również automatycznie ustawić numer poprawki. Numer przebiegu przepływu pracy może być używany jako numer poprawki. Ta konwencja pomaga zapewnić, że numery wersji są zawsze unikatowe, nawet jeśli nie zaktualizujesz innych składników numerów wersji.

Załóżmy na przykład, że używasz modułu Bicep, który został opublikowany przez inną osobę. Moduł ma numer 2.0.496wersji . Zobaczysz, że nowa wersja modułu jest dostępna z numerem 2.1.502wersji . Jedyną znaczącą zmianą jest numer wersji pomocniczej, który wskazuje, że nie należy oczekiwać zmiany powodującej niezgodność podczas korzystania z nowej wersji.

Uwaga

Semantyczne przechowywanie wersji jest sformalizowaną strukturą przechowywania wersji podobną do obsługi wersji wieloczęściowych. Semantyczne przechowywanie wersji zawiera dodatkowe składniki w numerze wersji oraz ścisłe reguły dotyczące tego, kiedy należy ustawić lub zresetować każdy składnik. Link do dodatkowych informacji na temat semantycznego przechowywania wersji znajduje się w podsumowaniu.

Twój zespół musi zdecydować, jak zdefiniować zmianę powodującą niezgodność na potrzeby przechowywania wersji. Załóżmy na przykład, że utworzono moduł Bicep, który wdraża konto magazynu. Teraz aktualizujesz plik Bicep, aby włączyć prywatne punkty końcowe na koncie magazynu. Dodajesz prywatną strefę DNS do pliku Bicep w tym samym czasie.

W tym przykładzie można wprowadzić zmianę bez wpływu na parametry lub dane wyjściowe pliku Bicep. W ten sposób każdy, kto wdraża plik, może nie zauważyć, że wszystko jest inne. Jednak ta zmiana wprowadza znaczącą różnicę w zachowaniu zasobów, więc możesz zdecydować się traktować ją jako aktualizację wersji głównej.

Możesz również użyć prostszej strategii przechowywania wersji, takiej jak użycie numeru przebiegu przepływu pracy jako numeru wersji. Chociaż takie podejście jest łatwiejsze do zaimplementowania, oznacza to, że nie można skutecznie komunikować różnic między wersjami dla każdego, kto używa kodu.

Wersje i przepływy pracy

Podczas interaktywnego publikowania kodu, takiego jak przy użyciu interfejsu wiersza polecenia platformy Azure, prawdopodobnie pomyśl o numerze wersji przypisanym do specyfikacji lub modułu szablonu podczas jego publikowania. Jednak w zautomatyzowanym przepływie pracy wdrażania należy zmienić podejście w celu przypisania numerów wersji. Przepływ pracy nie może automatycznie wykrywać zmian powodujących niezgodność ani doradzić, kiedy należy zwiększać główne lub pomocnicze numery wersji. Przed opublikowaniem specyfikacji lub modułu szablonu należy dokładnie rozważyć przechowywanie wersji.

Jednym z podejść jest przechowywanie pliku metadanych przy użyciu kodu Bicep, jak pokazano na poniższym diagramie:

Za każdym razem, gdy zaktualizujesz kod Bicep, zaktualizujesz informacje o wersji w odpowiednim pliku metadanych. Upewnij się, że prawidłowo identyfikujesz zmiany powodujące niezgodność i niełamające się, aby można było poprawnie zwiększać numery wersji.

Napiwek

Jeśli twój zespół przegląda kod Bicep przy użyciu żądań ściągnięcia, poproś recenzentów o sprawdzenie, czy jakiekolwiek zmiany w kodzie wymagają zmiany głównych lub pomocniczych numerów wersji.

Zobaczysz, jak można użyć pliku metadanych w następnym ćwiczeniu.

Ile przepływów pracy?

Często tworzy się kolekcję specyfikacji i modułów szablonu. Często warto zachować je w tym samym repozytorium Git.

Za pomocą filtrów ścieżek w funkcji GitHub Actions można tworzyć oddzielne przepływy pracy dla każdego modułu lub specyfikacji szablonu w repozytorium. Takie podejście pomaga uniknąć publikowania nowej wersji każdego pliku Bicep w repozytorium za każdym razem, gdy zmieniasz jeden plik. Możesz użyć przepływów pracy wielokrotnego użytku, aby zdefiniować kroki przepływu pracy w scentralizowanym pliku, który zapewnia uproszczony przepływ pracy poszczególnych modułów i specyfikacji szablonu.

Załóżmy na przykład, że masz strukturę plików podobną do przedstawionej wcześniej. Można skonfigurować trzy oddzielne przepływy pracy, po jednym dla każdego pliku Bicep. Wybierz każdą kartę, aby wyświetlić odpowiednią definicję przepływu pracy i jej filtr ścieżki:

module-1

name: 'publish-module-1'

on:
  push:
    branches:
      - main
    paths:
      - 'module-1/**'

jobs:
  publish:
    uses: ./.github/workflows/publish-module.yml
    with:
      path: 'module-1/main.bicep'

module-2

name: 'publish-module-2'

on:
  push:
    branches:
      - main
    paths:
      - 'module-2/**'

jobs:
  publish:
    uses: ./.github/workflows/publish-module.yml
    with:
      path: 'module-2/main.bicep'

template-spec-1

name: 'publish-template-spec-1'

on:
  push:
    branches:
      - main
    paths:
      - 'template-spec-1/**'

jobs:
  publish:
    uses: ./.github/workflows/publish-template-spec.yml
    with:
      path: 'template-spec-1/main.bicep'

Załóżmy, że zmieniasz tylko plik module-2/main.bicep . Tylko przepływ pracy dla modułu 2 jest uruchamiany. Jeśli jednak zmienisz wiele plików w tym samym zatwierdzeniu, każdy z odpowiednich przepływów pracy zostanie wyzwolony.

Uwaga

Podejście do tworzenia przepływu pracy dla każdego z plików Bicep wielokrotnego użytku jest proste i elastyczne. Jednak może to stać się kłopotliwe, gdy masz dużą liczbę plików Bicep lub jeśli nie chcesz obsługiwać oddzielnych przepływów pracy dla każdego modułu i specyfikacji szablonu.

Możesz również pisać skrypty w przepływie pracy, aby znaleźć zmieniony kod i opublikować tylko te pliki. Jest to bardziej złożone podejście i wykracza poza zakres tego modułu szkoleniowego usługi Microsoft Learn.

Środowiska do wielokrotnego użytku kodu Bicep

Podczas wdrażania na platformie Azure przy użyciu narzędzia Bicep często używa się wielu środowisk, aby ułatwić weryfikowanie i testowanie kodu przed opublikowaniem kodu w środowisku produkcyjnym. W poprzednich modułach szkoleniowych usługi Microsoft Learn przedstawiono sposób pracy z wieloma środowiskami z przepływu pracy wdrażania.

Niektóre organizacje stosują te same zasady do modułów Bicep i specyfikacji szablonu. Na przykład możesz najpierw opublikować nowe wersje modułów w rejestrze nieprodukcyjnym, aby użytkownicy każdego modułu mogli wypróbować nowe wersje. Następnie po ich wylogowaniu można opublikować moduły w rejestrze produkcyjnym organizacji.

Podobnie jak w przypadku zwykłych wdrożeń, można używać zadań i przepływów pracy wielokrotnego użytku do definiowania sekwencji wdrażania w środowiskach. W tym module szkoleniowym usługi Microsoft Learn publikujemy w jednym środowisku, aby zapewnić prostotę przepływu pracy.

Gdy używasz modułów z rejestru lub używasz specyfikacji szablonu jako modułu Bicep, możesz użyć aliasów. Zamiast określać nazwę rejestru lub lokalizację specyfikacji szablonu za każdym razem, gdy zdefiniujesz moduł, użyj jego aliasu.

Za pomocą aliasów możesz sprawić, że proces wdrażania będzie działać w wielu środowiskach. Na przykład podczas definiowania modułu można użyć aliasu zamiast nazwy rejestru. Następnie można zaprojektować przepływ pracy wdrażania, aby skonfigurować alias do zamapowania na:

• Rejestr modułów deweloperskich podczas wdrażania w środowisku piaskownicy.
• Rejestr produkcyjny podczas wdrażania w innych środowiskach.

Uwaga

Aliasy nie mają zastosowania podczas publikowania. Działają one tylko wtedy, gdy używasz specyfikacji szablonu lub modułów w pliku Bicep.