Klasyczne potoki wdrażania

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Potoki wydania klasycznego zapewniają deweloperom strukturę do wydajnego i bezpiecznego wdrażania aplikacji w wielu środowiskach. Korzystając z klasycznych potoków wydań, można zautomatyzować procesy testowania i wdrażania, skonfigurować elastyczne strategie wdrażania, uwzględnić przepływy pracy zatwierdzania i zapewnić płynne przejścia aplikacji na różne etapy.

Jak działają linie wydania

W ramach każdego wdrożenia usługa Azure Pipelines wykonuje następujące kroki:

1. Zatwierdzenie przed wdrożeniem:

   Po wyzwoleniu nowego żądania wdrożenia usługa Azure Pipelines sprawdza, czy przed wdrożeniem wydania na etapie konieczne jest zatwierdzenie wdrożenia wstępnego. Jeśli wymagane jest zatwierdzenie, wysyła powiadomienia e-mail do odpowiednich osób zatwierdzających.

2. Zadanie wdrożenia kolejki:

   Usługa Azure Pipelines planuje zadanie wdrożenia na dostępnym agencie.

3. Wybór agenta:

   Dostępny agent pobiera zadanie wdrożenia. Potok wydania można skonfigurować tak, aby dynamicznie wybierał odpowiedniego agenta podczas działania.

4. Pobieranie artefaktów:

   Agent pobiera wszystkie artefakty określone w wydaniu.

5. Uruchom zadania wdrażania

   Agent wykonuje wszystkie zadania w procesie wdrażania.

6. Generuj dzienniki postępu:

   Agent generuje kompleksowe dzienniki dla każdego kroku wdrażania i wysyła je z powrotem do usługi Azure Pipelines.

7. Zatwierdzenie po wdrożeniu:

   Po zakończeniu wdrażania na etapie, Azure Pipelines sprawdza, czy zatwierdzenie po wdrożeniu jest wymagane dla tego konkretnego etapu. Jeśli nie jest wymagane zatwierdzenie lub po uzyskaniu wymaganego zatwierdzenia, następuje zainicjowanie wdrożenia do następnego etapu.

Model wdrażania

Potoki wydań platformy Azure obsługują szeroką gamę źródeł artefaktów, takich jak Jenkins, Azure Artifacts i Team City. Poniższy przykład ilustruje model wdrażania przy użyciu potoków wydania platformy Azure:

W poniższym przykładzie potok zawiera dwa artefakty kompilacji pochodzące z oddzielnych potoków kompilacji. Aplikacja jest początkowo wdrażana na etapie deweloperskim , a następnie na dwóch oddzielnych etapach kontroli jakości . Jeśli wdrożenie zakończy się pomyślnie w obu etapach kontroli jakości, aplikacja zostanie wdrożona w pierścieniu Prod 1 , a następnie w pierścieniu Prod 2. Każdy pierścień produkcyjny reprezentuje wiele wystąpień tej samej aplikacji internetowej, wdrożonych w różnych lokalizacjach na całym świecie.

Wydania vs wdrożenia

Wydanie to konstrukcja, która zawiera wersjonowany zestaw artefaktów określony w potoku CI/CD. Zawiera migawkę wszystkich informacji potrzebnych do przeprowadzenia wszystkich zadań i działań w procesie wydania, takich jak etapy, zadania, zasady, w tym wyzwalacze i osoby zatwierdzające, oraz opcje wdrożeniowe. Może być wiele wydań z jednej ścieżki wydaniowej, a informacje o każdym z nich są przechowywane i wyświetlane w usłudze Azure Pipelines w określonym okresie przechowywania.

Wdrożenie to akcja uruchamiania zadań dla jednego etapu, który może obejmować uruchamianie testów automatycznych, wdrażanie artefaktów kompilacji i inne akcje określone dla tego etapu. Inicjowanie wydania rozpoczyna każde wdrożenie na podstawie ustawień i zasad zdefiniowanych w oryginalnym potoku wydania. Istnieje wiele wdrożeń każdej wersji nawet dla jednego etapu. Gdy wdrożenie wydania zakończy się niepowodzeniem na etapie, można ponownie wdrożyć tę samą wersję na tym etapie. Aby ponownie wdrożyć wydanie, po prostu przejdź do wydania, które chcesz wdrożyć i wybierz pozycję Wdróż.

Na poniższym diagramie przedstawiono relację między wydaniami, potokami wydania i wdrożeniami.

Często zadawane pytania

Dlaczego moje wdrożenie nie zostało uruchomione?

1: Tworzenie potoku wydania nie uruchamia wdrożenia automatycznie. Oto kilka powodów, dla których może się to zdarzyć:

• Wyzwalacze wdrażania: zdefiniowane wyzwalacze wdrażania mogą spowodować wstrzymanie wdrożenia. Może się to zdarzyć w przypadku zaplanowanych wyzwalaczy lub gdy występuje opóźnienie do zakończenia wdrażania do innego etapu.

• Zasady kolejkowania: te zasady określają kolejność wykonywania i moment, w którym wydania są kolejkowane do wdrożenia.

• Zatwierdzenia przed wdrożeniem lub bramy: określone etapy mogą wymagać zatwierdzeń lub bram przed wdrożeniem, uniemożliwiając wdrożenie do momentu spełnienia wszystkich zdefiniowanych warunków.

Jak mogę edytować zmienne podczas publikacji?

Na zakładce Zmienne potoku publikacji zaznacz pole wyboru Ustawialne w momencie wydania dla zmiennych, które chcesz zmodyfikować, gdy wydanie jest w kolejce.

Następnie podczas generowania nowej wersji można modyfikować wartości tych zmiennych.

Kiedy bardziej odpowiednie byłoby zmodyfikowanie wersji zamiast potoku, który ją definiuje?

Możesz edytować zatwierdzenia, zadania i zmienne instancji wydania. Jednak te zmiany będą dotyczyć tylko tego wystąpienia. Jeśli chcesz, aby zmiany miały zastosowanie do wszystkich przyszłych wersji, edytuj zamiast tego potok wydania.

Jakie są scenariusze, w których funkcja 'porzucenia wydania' jest przydatna?

Odp.: Jeśli nie planujesz ponownego używania wersji lub chcesz uniemożliwić jej używanie, możesz porzucić wydanie w następujący sposób: Pipelines (...) >>Porzuć. Nie można porzucić wydania, gdy wdrożenie zostało rozpoczęte; najpierw musisz anulować tę operację wdrożenia.

.: Jak mogę zarządzać nazewnictwem nowych wersji?

1: Domyślna konwencja nazewnictwa potoków wydania to numerowanie sekwencyjne, gdzie wydania mają nazwę Release-1, Release-2 itd. Istnieje jednak elastyczność dostosowywania schematu nazewnictwa przez zmodyfikowanie maski formatu nazwy wydania. Na karcie Opcje potoku wydania przejdź do strony Ogólne i dostosuj format nazwy wydania, aby odpowiadał twoim preferencjom.

Podczas określania maski formatu można użyć następujących wstępnie zdefiniowanych zmiennych. Przykład: następujący format nazwy wydania: Release $(Rev:rrr) for build $(Build.BuildNumber) $(Build.DefinitionName) utworzy następującą wersję: Wydanie 002 dla kompilacji 20170213.2 MySampleAppBuild.

Zmienna	opis
Rev: rr	Automatycznie zwiększana liczba z co najmniej określoną liczbą cyfr.
Data/data: ddMMyy	Bieżąca data z domyślnym formatem MMddyy. Obsługiwane są wszystkie kombinacje M/MM/MMM/MMMM, d/dd/ddd/dddd, y/yy/yyyy/yyyy, h/hh/H/HH, m/mm, s/ss.
System.TeamProject	Nazwa projektu, do którego należy ta kompilacja.
Release.ReleaseId	Identyfikator wydania, który jest unikatowy we wszystkich wydaniach w projekcie.
Release.DefinitionName	Nazwa pipeline'u wydawniczego, do którego należy bieżące wydanie.
Build.BuildNumber	Numer kompilacji zawarty w wydaniu. Jeśli wersja ma wiele kompilacji, jest to liczba kompilacji podstawowej.
Build.DefinitionName	Nazwa potoku kompilacji zawartej w wydaniu. Jeśli wersja ma wiele kompilacji, jest to nazwa potoku głównej kompilacji.
Artifact.ArtifactType	Typ źródła artefaktu połączonego z wydaniem. Na przykład może to być Azure Pipelines lub Jenkins.
Build.SourceBranch	Gałąź podstawowego źródła artefaktu. W przypadku Git jest to postać main, jeśli gałąź to refs/heads/main. W przypadku Kontroli wersji Team Foundation jest to w formie gałąź, jeśli ścieżka serwera głównego dla obszaru roboczego to $/teamproject/branch. Ta zmienna nie jest ustawiona dla serwera Jenkins ani innych źródeł artefaktów.
Zmienna niestandardowa	Wartość globalnej właściwości konfiguracji zdefiniowanej w potoku wydania. Nazwę wydania można zaktualizować przy użyciu zmiennych niestandardowych przy użyciu poleceń rejestrowania wydania

Jak mogę zdefiniować okres przechowywania dla moich wersji?

1: Zobacz zasady przechowywania, aby dowiedzieć się, jak skonfigurować zasady przechowywania dla potoków wydania.

Powiązane artykuły

• Wdrażanie artefaktów pull request
• Wdrażanie z wielu gałęzi
• Ustaw wieloetapowy potok wydawniczy