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.
Często zadawane pytania
Pyt.: 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.
Pyt.: 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.
Pyt.: 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.
Pyt.: 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 |
Pyt.: Jak mogę zdefiniować okres przechowywania dla moich wersji?
1: Zobacz zasady przechowywania, aby dowiedzieć się, jak skonfigurować zasady przechowywania dla potoków wydania.