Klasyczne potoki wydania
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ą potoki wydania
W ramach każdego wdrożenia usługa Azure Pipelines wykonuje następujące kroki:
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.
Zadanie wdrażania kolejki:
Usługa Azure Pipelines planuje zadanie wdrożenia na dostępnym agencie.
Wybór agenta:
Dostępny agent pobiera zadanie wdrożenia. Potok wydania można skonfigurować tak, aby dynamicznie wybierał odpowiedniego agenta w czasie wykonywania.
Pobieranie artefaktów:
Agent pobiera i pobiera wszystkie artefakty określone w wydaniu.
Uruchom zadania wdrażania:
Agent wykonuje wszystkie zadania w zadaniu wdrażania.
Generowanie dzienników postępu:
Agent generuje kompleksowe dzienniki dla każdego kroku wdrażania i wysyła je z powrotem do usługi Azure Pipelines.
Zatwierdzenie po wdrożeniu:
Po zakończeniu wdrażania na etapie usługa Azure Pipelines sprawdza, czy zatwierdzenie po wdrożeniu jest konieczne 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 składa się z dwóch artefaktów kompilacji pochodzących 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.
Wersje a wdrożenia
Wydanie to konstrukcja, która zawiera zestaw artefaktów w wersji określonych w potoku ciągłej integracji/ciągłego wdrażania. Zawiera migawkę wszystkich informacji wymaganych do wykonania wszystkich zadań i akcji w potoku wydania, takich jak etapy, zadania, zasady, takie jak wyzwalacze i osoby zatwierdzające oraz opcje wdrażania. Istnieje wiele wydań z jednego potoku wydania, a informacje o każdym z nich są przechowywane i wyświetlane w usłudze Azure Pipelines dla określonego okresu 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 wdrożenie nie zostało wyzwolone?
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ć z zaplanowanymi wyzwalaczami lub po zakończeniu wdrażania do innego etapu.
Zasady kolejkowania: te zasady określają kolejność wykonywania i czas kolejkowania wydań 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 w czasie wydania?
1: Na karcie Zmienne potoku wydania zaznacz pole wyboru Ustaw tabelę w czasie 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 byłoby bardziej odpowiednie zmodyfikowanie wydania zamiast potoku, który go definiuje?
1: Możesz edytować zatwierdzenia, zadania i zmienne wystąpienia 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 jest w toku, musisz najpierw anulować wdrożenie.
.: 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 właściwość Format nazwy wydania, aby odpowiadała 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: MMddyyy | Bieżąca data z domyślnym formatem MMddyy. Obsługiwane są wszystkie kombinacje M/MM/MMM/MMMM, d/ddd/dddd/dddd, y/y/rrrr,h/hh/H/H/H, 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 wersjach w projekcie. |
| Release.DefinitionName | Nazwa potoku wydania, do którego należy bieżąca wersja. |
| Build.BuildNumber | Liczba kompilacji zawartych 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 kompilacji podstawowej. |
| Artifact.ArtifactType | Typ źródła artefaktu połączonego z wydaniem. Na przykład może to być usługa Azure Pipelines lub Jenkins. |
| Build.SourceBranch | Gałąź podstawowego źródła artefaktu. W przypadku usługi Git jest to formularz główny , jeśli gałąź jest refs/head/main. W przypadku Kontrola wersji serwera Team Foundation jest to gałąź formularza, 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.