Projektowanie potoku
W tej lekcji wykonasz kroki zespołu internetowego Tailspin, definiując potok wydania dla witryny internetowej Space Game .
Podczas planowania potoku wydania zwykle zaczynasz od zidentyfikowania etapów lub głównych podziałów tego potoku. Każdy etap zwykle mapuje się na środowisko. Na przykład w poprzednim module podstawowy potok Andy'ego i Mary'ego miał etap Deploy (Wdrażanie), który został zamapowany na wystąpienie usługi aplikacja systemu Azure Service.
W tym module podwyższ poziom zmian z jednego etapu do następnego. W każdym etapie wdrażasz witrynę internetową Space Game w środowisku skojarzonym z tym etapem.
Po zdefiniowaniu potrzebnych etapów rozważ podwyższenie poziomu zmian z jednego etapu do następnego. Każdy etap może zdefiniować kryteria powodzenia, które muszą zostać spełnione, zanim kompilacja zostanie przeniesiona do następnego etapu. Usługa Azure Pipelines udostępnia kilka sposobów kontrolowania sposobu i kiedy zmiany przechodzą przez potok. W całości te podejścia są używane do zarządzania wydaniami.
W tej sekcji omówiono następujące zagadnienia:
- Poznaj różnice między typowymi etapami potoku, takimi jak kompilacja, tworzenie, testowanie i przemieszczanie.
- Dowiedz się, jak używać wyzwalaczy ręcznego, zaplanowanego i ciągłego wdrażania, aby kontrolować, kiedy artefakt przechodzi do następnego etapu w potoku.
- Zobacz, jak zatwierdzenie wydania wstrzymuje potok, dopóki osoba zatwierdzająca nie zaakceptuje lub odrzuci wydanie.
Spotkanie
Cały zespół internetowy Tailspin jest zbierany razem. W obszarze Tworzenie potoku wydania za pomocą usługi Azure Pipelines zespół planował swoje zadania dla bieżącego przebiegu. Każde zadanie odnosi się do tworzenia potoku wydania dla witryny internetowej Space Game .
Przypomnij sobie, że zespół zdecydował się na te pięć zadań na potrzeby przebiegu:
- Utwórz potok wieloestowy.
- Połączenie aplikacji internetowej do bazy danych.
- Automatyzowanie testów jakości.
- Automatyzowanie testów wydajnościowych.
- Popraw cykl wydania.
Zespół spotyka się, aby porozmawiać o pierwszym zadaniu, Tworzenie potoku wieloestegożowego. Po zdefiniowaniu potoku zespół może przejść od podstawowego weryfikacji koncepcji do potoku wydania, który zawiera więcej etapów, kontroli jakości i zatwierdzeń.
Amita i Tim oglądają Andy'ego i Marę po raz drugi demonstrują potok wydania. Widzą, że artefakt został skompilowany i zainstalowany w usłudze App Service.
Jakich etapów potoku potrzebujesz?
Jeśli chcesz zaimplementować potok wydania, ważne jest, aby najpierw określić, które etapy są potrzebne. Wybrane etapy zależą od wymagań. Śledźmy razem z zespołem, gdy decydują się na ich etapy.
Tim: OK, rozumiem pomysł zautomatyzowanego potoku. Podoba mi się, jak łatwo jest wdrożyć na platformie Azure. Ale gdzie przechodzimy z tej demonstracji? Potrzebujemy czegoś, czego faktycznie możemy użyć dla naszych wydań.
Amita: Prawo! Musimy dodać inne etapy. Na przykład obecnie nie mamy miejsca na etap testowania.
Tim: Plus potrzebujemy etapu, w którym możemy pokazać nowe funkcje do zarządzania. Nie mogę wysłać niczego do środowiska produkcyjnego bez zatwierdzenia zarządzania.
Andy: Absolutnie! Teraz, gdy jest to możliwe, aby przyspieszyć działanie potoku wydania, jak sprawić, aby ten potok zrobił to, czego potrzebujemy?
Mara: Naszkicujmy nasze wymagania, aby pomóc nam zaplanować kolejne kroki. Zacznijmy od tego, co mamy.
Mara przenosi się do tablicy i szkicuje istniejący potok.
Mara: Etap kompilacji kompiluje kod źródłowy i tworzy pakiet. W naszym przypadku ten pakiet jest plikiem zip . Etap Wdrażania instaluje plik zip , który jest witryną internetową Space Game , w wystąpieniu usługi App Service. Czego brakuje w potoku wydania?
Dodawanie etapu deweloperskiego
Andy: Mógłbym być stronniczy, ale myślę, że potrzebujemy etapu Dev . Ten etap powinien być pierwszym zatrzymaniem artefaktu po jego skompilowanych elementach. Deweloperzy nie zawsze mogą uruchamiać całą usługę ze swojego lokalnego środowiska deweloperskiego. Na przykład system handlu elektronicznego może wymagać witryny internetowej, bazy danych produktów i systemu płatności. Potrzebujemy etapu, który obejmuje wszystko, czego potrzebuje aplikacja.
W naszym przypadku funkcja rankingowa witryny Space Game odczytuje wysokie wyniki ze źródła zewnętrznego. W tej chwili odczytuje fikcyjne wyniki z pliku. Skonfigurowanie etapu deweloperskiego dałoby nam środowisko, w którym można zintegrować aplikację internetową z prawdziwą bazą danych. Ta baza danych może nadal przechowywać fikcyjne wyniki, ale przybliża nas o krok do naszej ostatecznej aplikacji.
Mara: Podoba mi się. Nie będziemy jeszcze integrować się z prawdziwą bazą danych. Jednak na etapie deweloperskim możemy wdrożyć w środowisku, w którym możemy dodać bazę danych.
Mara aktualizuje swój rysunek na tablicy. Zastępuje element "Deploy" ciągiem "Dev", aby wyświetlić etap Dev .
Andy: Wychowasz ciekawy punkt. Tworzymy aplikację za każdym razem, gdy wypychamy zmianę do usługi GitHub. Czy oznacza to, że każda kompilacja jest promowana do etapu deweloperskiego po zakończeniu?
Mara: Ciągłe budowanie daje nam ważne informacje na temat naszej kondycji kompilacji i testowania. Chcemy jednak podwyższyć poziom do etapu deweloperskiego tylko wtedy, gdy scalamy kod z gałęzią centralną: główną lub inną gałęzią wydania. Zaktualizuję rysunek, aby pokazać to wymaganie.
Mara: Myślę, że ta promocja będzie łatwa do osiągnięcia. Możemy zdefiniować warunek , który podwyższa poziom do etapu deweloperskiego tylko wtedy, gdy zmiany zostaną wprowadzone w gałęzi wydania.
Co to są warunki?
W usłudze Azure Pipelines użyj warunku do uruchomienia zadania lub zadania na podstawie stanu potoku. Pracowaliśmy z warunkami w poprzednich modułach.
Pamiętaj, że niektóre warunki, które można określić, to:
- Tylko wtedy, gdy wszystkie poprzednie zadania zależne zakończyły się pomyślnie.
- Nawet jeśli poprzednia zależność nie powiodła się, chyba że przebieg został anulowany.
- Nawet jeśli poprzednia zależność nie powiodła się, nawet jeśli przebieg został anulowany.
- Tylko wtedy, gdy poprzednia zależność nie powiodła się.
- Niektóre warunki niestandardowe.
Poniżej przedstawiono prosty przykład:
steps:
- script: echo Hello!
condition: always()
Warunek always() powoduje, że to zadanie wyświetla "Hello!" bezwarunkowo, nawet jeśli poprzednie zadania nie powiodły się.
Ten warunek jest używany, jeśli nie określisz warunku:
condition: succeeded()
Wbudowana succeeded() funkcja sprawdza, czy poprzednie zadanie zakończyło się pomyślnie. Jeśli poprzednie zadanie zakończy się niepowodzeniem, to zadanie i późniejsze zadania, które używają tego samego warunku, zostaną pominięte.
W tym miejscu chcesz utworzyć warunek określający:
- Poprzednie zadanie zakończyło się pomyślnie.
- Nazwa bieżącej gałęzi Git to wydanie.
Aby utworzyć ten warunek, użyjesz wbudowanej funkcji and(). Ta funkcja sprawdza, czy każdy z jego warunków jest spełniony. Jeśli jakikolwiek warunek nie jest spełniony, ogólny warunek zakończy się niepowodzeniem.
Aby uzyskać nazwę bieżącej gałęzi, należy użyć wbudowanej Build.SourceBranchName zmiennej. Możesz uzyskać dostęp do zmiennych w ramach warunku na kilka sposobów. W tym miejscu użyjesz variables[] składni.
Aby przetestować wartość zmiennej, możesz użyć wbudowanej funkcji eq(). Ta funkcja sprawdza, czy jej argumenty są równe.
Mając to na uwadze, należy zastosować ten warunek, aby uruchomić etap deweloperski tylko wtedy, gdy bieżąca nazwa gałęzi to "release":
condition: |
and
(
succeeded(),
eq(variables['Build.SourceBranchName'], 'release')
)
Pierwszy warunek funkcji and() sprawdza, czy poprzednie zadanie zakończyło się pomyślnie. Drugi warunek sprawdza, czy bieżąca nazwa gałęzi jest równa wydaniu.
W języku YAML należy użyć składni potoku (|), aby zdefiniować ciąg obejmujący wiele wierszy. Warunek można zdefiniować w jednym wierszu, ale napisanie go w wielu wierszach sprawia, że jest bardziej czytelny.
Uwaga
W tym module użyjemy gałęzi wydania jako przykładu. Możesz połączyć warunki, aby zdefiniować potrzebne zachowanie. Można na przykład utworzyć warunek, który uruchamia etap tylko wtedy, gdy kompilacja jest wyzwalana przez żądanie ściągnięcia względem gałęzi głównej.
W następnej lekcji podczas konfigurowania etapu deweloperskiego będziesz pracować z bardziej kompletnym przykładem.
Aby uzyskać bardziej szczegółowy opis warunków w usłudze Azure Pipelines, zobacz dokumentację wyrażeń.
Mara: korzystając z warunków, można kontrolować, które zmiany są promowane do poszczególnych etapów. Możemy utworzyć artefakt kompilacji dla każdej zmiany, aby zweryfikować naszą kompilację i potwierdzić, że jest ona w dobrej kondycji. Gdy wszystko będzie gotowe, możemy scalić te zmiany w gałęzi wydania i podwyższyć poziom tej kompilacji do etapu deweloperskiego.
Dodawanie etapu testu
Mara: Do tej pory mamy etapy Kompilacja i Tworzenie . Co dalej?
Amita: Czy możemy dodać następny etap testu ? To wydaje się właściwym miejscem dla mnie do przetestowania najnowszych zmian.
Mara dodaje etap Test do swojego rysunku na tablicy.
Amita: Jednym z problemów, które mam, jest to, jak często muszę przetestować aplikację. Wiadomość e-mail powiadamia mnie za każdym razem, gdy Mara lub Andy dokona zmiany. Zmiany zdarzają się przez cały dzień i nigdy nie wiem, kiedy wskoczyć. Myślę, że chciałbym zobaczyć kompilację raz dziennie, być może kiedy dojdę do biura. Czy możemy to zrobić?
Andy: Na pewno. Dlaczego nie wdrażamy w usłudze Test w godzinach pracy? Załóżmy, że codziennie wysyłamy ci kompilację o godzinie 3:00.
Mara: To brzmi dobrze. Zawsze możemy ręcznie wyzwolić proces, jeśli zajdzie taka potrzeba. Na przykład możemy go wyzwolić, jeśli potrzebujemy od razu zweryfikować ważną poprawkę usterki.
Mara aktualizuje swój rysunek, aby pokazać, że kompilacja przechodzi od etapu Dev do etapu testowego o 3 rano.
Co to są wyzwalacze?
Amita: Czuję się teraz lepiej, że wiemy, jak jeden etap porusza się do drugiego. Ale jak kontrolować, kiedy etap jest uruchamiany?
Mara: w usłudze Azure Pipelines możemy użyć wyzwalaczy. Wyzwalacz określa, kiedy etap jest uruchamiany. Usługa Azure Pipelines udostępnia kilka typów wyzwalaczy. Oto nasze wybory:
- Wyzwalacz ciągłej integracji
- Wyzwalacz żądania ściągnięcia (PR)
- Wyzwalacz zaplanowany
- Wyzwalacz uzupełniania kompilacji
Wyzwalacze ciągłej integracji i żądania ściągnięcia umożliwiają kontrolowanie gałęzi uczestniczących w ogólnym procesie. Na przykład chcesz skompilować projekt po wprowadzeniu zmiany w dowolnej gałęzi. Zaplanowany wyzwalacz uruchamia wdrożenie w określonym czasie. Wyzwalacz ukończenia kompilacji uruchamia kompilację, gdy inna kompilacja, taka jak jedna dla składnika zależnego, zakończy się pomyślnie. Wygląda na to, że chcemy zaplanowanego wyzwalacza.
Co to są zaplanowane wyzwalacze?
Zaplanowany wyzwalacz używa składni cron, aby spowodować uruchomienie kompilacji zgodnie ze zdefiniowanym harmonogramem.
W systemach Unix i Linux cron to popularny sposób planowania zadań do uruchamiania w określonym przedziale czasu lub w określonym czasie. W usłudze Azure Pipelines zaplanowane wyzwalacze używają składni cron do zdefiniowania, kiedy etap jest uruchamiany.
Wyrażenie cron zawiera pola zgodne z określonymi parametrami czasu. Oto pola:
mm HH DD MM DW
\ \ \ \ \__ Days of week
\ \ \ \____ Months
\ \ \______ Days
\ \________ Hours
\__________ Minutes
Na przykład to wyrażenie cron opisuje "3:00 każdego dnia": 0 3 * * *
Wyrażenie cron może zawierać znaki specjalne, aby określić listę wartości lub zakres wartości. W tym przykładzie gwiazdka (*) odpowiada wszystkim wartościom pól Dni, Miesięcy i Dni tygodnia .
Mówiąc inaczej, to wyrażenie cron odczytuje jako:
- W minucie 0,
- W trzeciej godzinie,
- W dowolnym dniu miesiąca,
- W dowolnym miesiącu,
- W dowolnym dniu tygodnia,
- Uruchamianie zadania
Aby określić 3:00 tylko w dni od poniedziałku do piątku, użyj następującego wyrażenia: 0 3 * * 1-5
Uwaga
Strefa czasowa harmonogramów cron to uniwersalny czas koordynowany (UTC), więc w tym przykładzie 3:00 odnosi się do 3:00 w formacie UTC. W praktyce możesz dostosować czas w harmonogramie cron względem czasu UTC, aby potok był uruchamiany w oczekiwanym czasie dla Ciebie i Twojego zespołu.
Aby skonfigurować zaplanowany wyzwalacz w usłudze Azure Pipelines, potrzebujesz schedules sekcji w pliku YAML. Oto przykład:
schedules:
- cron: '0 3 * * *'
displayName: 'Deploy every day at 3 A.M.'
branches:
include:
- release
always: false
W tej schedules sekcji:
cronokreśla wyrażenie cron.branchesokreśla, aby wdrożyć tylko zreleasegałęzi.alwaysOkreśla, czy należy uruchomić wdrożenie bezwarunkowo (true), czy tylko wtedy, gdyreleasegałąź uległa zmianie od ostatniego uruchomienia (false). W tym miejscu należy określićfalse, ponieważ należy wdrożyć tylko wtedy, gdyreleasegałąź zmieniła się od ostatniego uruchomienia.
Cały potok jest uruchamiany, gdy usługa Azure Pipelines wykonuje zaplanowany wyzwalacz. Potok działa również w innych warunkach, takich jak wypychanie zmiany do usługi GitHub. Aby uruchomić etap tylko w odpowiedzi na zaplanowany wyzwalacz, można użyć warunku sprawdzającego, czy przyczyną kompilacji jest zaplanowany przebieg.
Oto przykład:
- stage: 'Test'
displayName: 'Deploy to the Test environment'
condition: and(succeeded(), eq(variables['Build.Reason'], 'Schedule'))
Ten etap , jest uruchamiany tylko wtedy, Testgdy poprzedni etap zakończy się pomyślnie, a wbudowana Build.Reason zmienna potoku równa Schedule.
W dalszej części tego modułu zostanie wyświetlony bardziej kompletny przykład.
Amita: Podoba mi się to. Nie muszę nawet ręcznie pobierać wydania i instalować go. To jest dla mnie gotowe.
Andy: I pamiętaj, że jeśli chcemy zautomatyzować więcej później, możemy. Nic nie jest napisane w kamieniu. Potok ewoluuje w miarę ulepszania i uczenia się.
Dodawanie etapu przejściowego
Tim: To moja kolej. Potrzebuję etapu, aby uruchomić więcej testów obciążeniowych. Potrzebujemy również etapu, w którym możemy przeprowadzić pokaz zarządzania, aby uzyskać ich zatwierdzenie. Na razie możemy połączyć te dwa potrzeby w etap, który możemy wywołać przejściowe.
Andy: Cóż, powiedział, Tim. Posiadanie środowiska przejściowego lub przedprodukcyjnego jest ważne. To środowisko przejściowe jest często ostatnim zatrzymaniem, zanim funkcja lub poprawka usterek dotrą do naszych użytkowników.
Mara dodaje inscenizacji do swojego rysunku na tablicy.
Amita: Używamy zaplanowanego wyzwalacza, aby podwyższyć poziom zmian z etapu deweloperskiego do etapu testowego. Jak jednak podwyższyć poziom zmian z testowych do przejściowych? Czy ta promocja również musi nastąpić zgodnie z harmonogramem?
Mara: Myślę, że najlepszym sposobem, aby poradzić sobie z tym byłoby zatwierdzenie wydania. Zatwierdzenie wydania umożliwia ręczne podwyższenie poziomu zmiany z jednego etapu do następnego.
Amita: To brzmi dokładnie tak, czego potrzebuję! Zatwierdzenie wydania dałoby mi czas na przetestowanie najnowszych zmian, zanim przedstawimy kompilację do zarządzania. Mogę promować kompilację, gdy jestem gotowy.
Mara aktualizuje jej rysunek, aby pokazać, że kompilacja zostanie przeniesiona z testu do przejściowego tylko wtedy, gdy Amita ją zatwierdzi.
Tim: Mógłbym również sobie wyobrazić korzystanie z zatwierdzeń wydań do promowania z staging do Production po zakończeniu zarządzania. Nigdy nie mogę przewidzieć, jak długo to trwa. Po wylogowaniu mogę zatwierdzić wydanie i podwyższyć jej poziom do środowiska produkcyjnego ręcznie. Ale jak działają zatwierdzenia wydań?
Co to są zatwierdzenia wersji?
Zatwierdzenie wydania to sposób wstrzymania potoku do momentu zaakceptowania lub odrzucenia wydania przez osoby zatwierdzające. Aby zdefiniować przepływ pracy wydania, możesz połączyć zatwierdzenia, warunki i wyzwalacze.
Pamiętaj, że w artykule Tworzenie potoku wydania za pomocą usługi Azure Pipelines zdefiniowano środowisko w konfiguracji potoku, które będzie reprezentować środowisko wdrażania. Oto przykład z istniejącego potoku:
- stage: 'Deploy'
displayName: 'Deploy the web application'
dependsOn: Build
jobs:
- deployment: Deploy
pool:
vmImage: 'ubuntu-20.04'
environment: dev
variables:
- group: Release
Środowisko może zawierać określone kryteria wydania. Kryteria mogą określać, które potoki mogą być wdrażane w tym środowisku i jakie zatwierdzenia człowieka są potrzebne do promowania wydania z jednego etapu do następnego.
W dalszej części tego modułu zdefiniujesz środowisko przejściowe i przypiszesz sobie rolę osoby zatwierdzającej, aby podwyższyć poziom aplikacji internetowej Space Game z etapu testowego do etapu przejściowego.
Automatyzuj jak najmniejszą lub tyle, ile potrzebujesz
Usługa Azure Pipelines zapewnia elastyczność automatyzowania niektórych etapów przy jednoczesnym ręcznym kontrolowaniu etapów, które nie są gotowe do automatyzacji.
Tim: Lubię, jak możemy zdefiniować kryteria, które promują zmiany z jednego etapu do następnego. Zdefiniowaliśmy jednak pewne kryteria ręczne w naszym potoku. Myślałem, że DevOps chodzi o automatyzację wszystkiego.
Mara: Podnosisz dobry punkt. Metodyka DevOps naprawdę polega na automatyzowaniu powtarzających się i podatnych na błędy zadań. Czasami konieczna jest interwencja człowieka. Na przykład uzyskujemy zatwierdzenie z zarządzania przed udostępnieniem nowych funkcji. W miarę uzyskiwania większego doświadczenia z naszymi zautomatyzowanymi wdrożeniami możemy zautomatyzować więcej naszych ręcznych kroków, aby przyspieszyć proces. Na przykład możemy zautomatyzować więcej kontroli jakości na etapie testu , więc Amita nie musi zatwierdzać każdej kompilacji.
Tim: Brzmi świetnie. Przejdźmy teraz do tego planu i zobaczmy, jak możemy przyspieszyć system później.
Amita: Czy możemy podsumować nasze następne kroki?
Plan
Przyjrzyjmy się planowi zespołu Tailspin w miarę przechodzenia do następnych kroków.
Mara: Oto potok wydania, który chcemy skompilować.
Mara wskazuje na tablicę.
Mara: Podsumowując, nasze kroki to:
- Tworzy artefakt kompilacji za każdym razem, gdy wypychamy zmianę do usługi GitHub. Ten krok odbywa się na etapie kompilacji.
- Podwyższ poziom artefaktu kompilacji do etapu Deweloper . Ten krok odbywa się automatycznie, gdy etap kompilacji zakończy się pomyślnie, a zmiana jest w gałęzi wydania.
- Podwyższanie poziomu artefaktu kompilacji do etapu testowego każdego ranka o godzinie 3:00. Do automatycznego podwyższania poziomu artefaktu kompilacji używamy zaplanowanego wyzwalacza.
- Podwyższanie poziomu artefaktu kompilacji do etapu przejściowego po testach Amita i zatwierdza kompilację. Do podwyższenia poziomu artefaktu kompilacji używamy zatwierdzenia wydania.
Po zatwierdzeniu kompilacji przez zarządzanie możemy wdrożyć artefakt kompilacji w środowisku produkcyjnym.
Amita: Czy to będzie trudne do zrobienia? Wydaje się, że dużo pracy.
Mara: Nie sądzę, że to zbyt złe. Każdy etap jest oddzielony od każdego innego etapu. Etapy są dyskretne. Każdy etap ma własny zestaw zadań. Na przykład to, co dzieje się na etapie testu, pozostaje na etapie testowym.
Każdy etap wdrażania w naszym potoku ma również własne środowisko. Na przykład podczas wdrażania aplikacji w środowisku tworzeniem lub testowaniem środowisko jest wystąpieniem usługi App Service.
Na koniec testujemy tylko jedną wersję naraz. Nigdy nie zmieniamy wersji w środku potoku. Używamy tej samej wersji na etapie deweloperskim , co na etapie przemieszczania , a każda wersja ma własny numer wersji. Jeśli wydanie zostanie zerwane na jednym z etapów, naprawimy go i skompilujemy go ponownie przy użyciu nowego numeru wersji. To nowe wydanie przechodzi następnie przez potok od samego początku.
Kilka słów o jakości
Właśnie pokazano, jak zespół zaprojektował potok, który przenosi aplikację przez całą drogę od kompilacji do etapu przejściowego. Cały punkt tego potoku nie jest tylko ułatwieniem ich życia. Jest to zapewnienie jakości oprogramowania dostarczanego przez nich klientom.
Jak zmierzyć jakość procesu wydania? Jakość procesu wydania nie może być mierzona bezpośrednio. To, co można zmierzyć, to jak dobrze działa proces. Jeśli stale zmieniasz proces, może to wskazywać, że coś jest nie tak. Wydania, które stale kończą się niepowodzeniem w określonym punkcie potoku, mogą również wskazywać, że występuje problem z procesem wydania.
Czy wydania zawsze kończą się niepowodzeniem w określonym dniu lub o określonej godzinie? Czy zawsze kończą się niepowodzeniem po wdrożeniu w określonym środowisku? Poszukaj tych i innych wzorców, aby sprawdzić, czy niektóre aspekty procesu wydania są zależne lub powiązane.
Dobrym sposobem na śledzenie jakości procesu wydania jest utworzenie wizualizacji jakości wydań. Na przykład dodaj widżet pulpitu nawigacyjnego, który pokazuje stan każdej wersji.
Jeśli chcesz zmierzyć jakość samego wydania, możesz wykonać wszystkie rodzaje kontroli w potoku. Na przykład można wykonywać różne typy testów, takich jak testy obciążeniowe i testy interfejsu użytkownika podczas uruchamiania potoku.
Korzystanie z bramy jakości jest również doskonałym sposobem na sprawdzenie jakości wydania. Istnieje wiele różnych bram jakości. Na przykład bramy elementów roboczych mogą zweryfikować jakość procesu wymagań. Możesz również dodać więcej kontroli zabezpieczeń i zgodności. Na przykład czy przestrzegasz zasady czterech oczu, czy masz odpowiednią możliwość śledzenia?
Podczas przechodzenia przez tę ścieżkę szkoleniową zobaczysz wiele z tych technik w praktyce.
Na koniec podczas projektowania procesu wydania jakości zastanów się nad rodzajem dokumentacji lub informacji o wersji, które należy podać użytkownikowi. Utrzymywanie bieżącej dokumentacji może być trudne. Warto rozważyć użycie narzędzia, takiego jak generator informacji o wersji usługi Azure DevOps. Generator to aplikacja funkcji, która zawiera funkcję wyzwalaną przez protokół HTTP. Za pomocą usługi Azure Blob Storage tworzy plik Markdown za każdym razem, gdy nowa wersja zostanie utworzona w usłudze Azure DevOps.