Zaprojektuj pipeline
- 11 min
W tej jednostce podążasz za zespołem internetowym Tailspin, definiując pipeline wdrożeniowy dla witryny Space Game.
Podczas planowania potoku wydania zwykle zaczynasz od zidentyfikowania etapów ,lub głównych sekcji tego potoku. Każdy etap zazwyczaj odpowiada środowisku. Na przykład w poprzednim module podstawowy potok Andy'ego i Mary'ego miał etap wdrażania , który został zamapowany na wystąpienie usługi Azure App Service.
W tym module przekształcasz zmiany z jednego etapu do następnego. Na każdym etapie wdrożyszSpace Game w środowisku skojarzonym z tym etapem witrynę internetową.
Po zdefiniowaniu potrzebnych etapów rozważ, jak zmiany są awansowane 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 tego, jak i kiedy zmiany przechodzą przez potok. W całości te podejścia są używane do zarządzania wydaniami.
W tej sekcji Ty:
- Poznaj różnice między typowymi etapami potoku, takimi jak Budowanie, Rozwój, Testowaniei Etapowanie.
- Dowiedz się, jak używać mechanizmów wyzwalających ręczne, planowane i ciągłe wdrażanie, aby kontrolować, kiedy artefakt przechodzi do kolejnego etapu w procesie.
- Zobacz, jak zatwierdzenie wydania wstrzymuje przepływ pracy, dopóki osoba zatwierdzająca nie zaakceptuje lub nie odrzuci wydania.
Spotkanie
Cały zespół internetowy Tailspin jest zebrany razem. W rozdziale Tworzenie potoku wdrożeniowego w usłudze Azure Pipelines zespół planował swoje zadania na bieżący sprint. Każde zadanie dotyczy tworzenia potoku wydawniczego dla witryny internetowej Space Game.
Przypomnij sobie, że zespół zdecydował się na te pięć zadań na potrzeby sprintu:
- Tworzenie potoku wielostopniowego
- Łączenie aplikacji internetowej z bazą danych
- Automatyzowanie testów jakości
- Automatyzowanie testów wydajnościowych
- Zwiększanie tempa wydania
Zespół spotyka się, aby porozmawiać o pierwszym zadaniu, jakim jest stworzenie potoku wieloetapowego . Po zdefiniowaniu potoku zespół może przejść od podstawowego dowodu koncepcji do potoku wydania zawierającego więcej etapów, kontroli jakości oraz zatwierdzeń.
Amita i Tim po raz drugi oglądają, jak Andy i Mara demonstrują pipeline wydawniczy. Widzą, że artefakt został skompilowany i zainstalowany w usłudze App Service.
Jakich etapów procesu potrzebujesz?
Jeśli chcesz zaimplementować potok wydania, ważne jest, aby najpierw określić, które etapy są potrzebne. Wybrane etapy zależą od wymagań. Podążajmy śladem zespołu, gdy decydują o swoich kolejnych etapach.
Tim: OK, rozumiem pomysł zautomatyzowanego potoku. Podoba mi się, jak łatwo jest wdrożyć na platformie Azure. Ale dokąd idziemy dalej po tym pokazie? Potrzebujemy czegoś, czego faktycznie możemy użyć dla naszych wydań.
Amita: Prawy! Musimy dodać inne etapy. Na przykład obecnie nie mamy miejsca na etap testowania.
Tim: Ponadto 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 mamy lepsze zrozumienie, co robi potok 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 podchodzi do tablicy i szkicuje istniejący rurociąg.
Mara: Etap kompilacji kompiluje kod źródłowy i tworzy pakiet. W naszym przypadku ten pakiet jest plikiem .zip . Etap Deploy instaluje plik .zip, który jest stroną internetową Space Game na instancji usługi App Service. Czego brakuje w procesie wydawniczym?
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 zbudowaniu. 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 rankingu na stronie internetowej Space Game pobiera 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. Zamienia "Deploy" na "Dev", aby pokazać etap Dev.
Andy: Podnosisz interesujący punkt. Tworzymy aplikację za każdym razem, gdy wprowadzamy zmiany w GitHubie. Czy oznacza to, że każda kompilacja jest promowana do etapu Dev po zakończeniu?
Mara: Ciągły proces budowania daje nam ważne informacje zwrotne na temat stanu naszej kompilacji i testowania. Chcemy jednak podwyższyć poziom do etapu Dev tylko wtedy, gdy scalimy 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 przechodzi do etapu Dev 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 pracy na podstawie stanu potoku. Pracowałeś 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 wykonanie zostało anulowane
- Tylko wtedy, gdy poprzednia zależność nie powiodła się
- Jakiś niestandardowy warunek
Oto podstawowy 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 funkcja succeeded() 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 release.
Aby utworzyć ten warunek, należy użyć 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 zmiennej Build.SourceBranchName. Możesz uzyskać dostęp do zmiennych w ramach warunku na kilka sposobów. W tym miejscu użyjesz składni variables[].
Aby przetestować wartość zmiennej, możesz użyć wbudowanej funkcji eq(). Ta funkcja sprawdza, czy jego argumenty są równe.
Mając to na uwadze, należy zastosować ten warunek, aby uruchomić etap Dev 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 release.
W języku YAML używa się składni z pionową kreską (|), aby zdefiniować ciąg obejmujący wiele wierszy. Warunek można zdefiniować w jednym wierszu, ale zapisujemy go w ten sposób, aby był bardziej czytelny.
Notatka
W tym module jako przykład użyjemy gałęzi release. 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 pull request względem głównej gałęzi .
W następnej jednostce, podczas konfigurowania etapu Dev, pracujesz na bardziej kompletnym przykładzie.
Aby uzyskać bardziej szczegółowy opis warunków w usłudze Azure Pipelines, zobacz dokumentację dotyczącą wyrażeń .
Mara: Za pomocą 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 działa poprawnie. Gdy wszystko będzie gotowe, możemy scalić te zmiany w gałęzi release i przenieść tę kompilację do etapu Dev.
Dodaj etap testowy
Mara: Do tej pory mamy etapy Kompilacja i Tworzenie . Co dalej?
Amita: Czy możemy dodać następny etap Test? To wydaje się właściwym miejscem dla mnie do przetestowania najnowszych zmian.
Mara dodaje etap Test do 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ę w ciągu całego dnia, i nigdy nie wiem, kiedy włączyć się. Chyba chciałbym widzieć build raz dziennie, może gdy przyjdę do biura. Czy możemy to zrobić?
Andy: Jasne. Dlaczego nie wdrażamy w usłudze Test poza godzinami 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, abyś 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 każdego dnia.
Co to są wyzwalacze?
Amita: Czuję się teraz lepiej, że wiemy, jak jeden etap przenosi się do innego. Ale jak kontrolować, kiedy etap jest uruchamiany?
Mara: w usłudze Azure Pipelines możemy użyć wyzwalaczy. Wyzwalacz definiuje, 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 zakończenia budowania
Wyzwalacze CI i pull requestów pozwalają na kontrolowanie, które gałęzie biorą udział 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 do uruchomienia 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 jest interpretowane 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
Notatka
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 pipeline uruchamiał się o oczekiwanej porze dla Ciebie i Twojego zespołu.
Aby skonfigurować zaplanowany wyzwalacz w usłudze Azure Pipelines, potrzebujesz sekcji schedules 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 sekcji schedules:
-
cronokreśla wyrażenie cron. -
branchesokreśla, aby wdrożenie było wykonywane tylko z gałęzirelease. -
alwaysokreśla, czy należy uruchomić wdrożenie bezwarunkowo (true), czy tylko wtedy, gdy gałąźreleasezmieniła się od ostatniego uruchomienia (false). W tym miejscu należy określićfalse, ponieważ należy wdrożyć tylko wtedy, gdy gałąźreleasezmieniła się od ostatniego uruchomienia.
Cały proces jest uruchamiany, gdy usługa Azure Pipelines aktywuje zaplanowany wyzwalacz. Potok działa również w innych warunkach, takich jak przesłanie zmiany na 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, Test, uruchamia się tylko wtedy, gdy poprzedni etap zakończy się pomyślnie, a wbudowana zmienna potokowa Build.Reason jest 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: Pamiętaj, że jeśli chcemy zautomatyzować więcej później, możemy. Nic nie jest napisane w kamieniu. Rurociąg ewoluuje w miarę jak się rozwijamy i uczymy.
Dodawanie etapu przejściowego
Tim: To moja kolej. Potrzebuję platformy testowej, aby przeprowadzić więcej testów obciążeniowych. Potrzebujemy również sceny, na której możemy zaprezentować się kierownictwu, aby uzyskać ich zatwierdzenie. Na razie możemy połączyć te dwie potrzeby w etap, który możemy nazwać Staging.
Andy: Dobrze powiedziane, Tim. Ważne jest, aby mieć środowisko przejściowelub przedprodukcyjne. To środowisko przejściowe jest często ostatnim zatrzymaniem, zanim funkcja lub poprawka usterek dotrą do naszych użytkowników.
Mara dodaje aranżację do swojego rysunku na tablicy.
Amita: Używamy planowanego wyzwalacza, aby promować zmiany z etapu Dev do etapu Test. Ale jak przenieść zmiany z Test do Staging? 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 przesunięcie 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ć build, gdy będę gotowy.
Mara aktualizuje swój rysunek, aby pokazać, że kompilacja przenosi się z Test do Przygotowanie tylko wtedy, gdy Amita ją zatwierdzi.
Tim: Mogę również sobie wyobrazić używanie zatwierdzeń wydań do promowania ze Stagingu do produkcji po zatwierdzeniu przez zarząd. Nigdy nie mogę przewidzieć, jak długo to trwa. Po wyrażeniu zgody mogę zatwierdzić wydanie i wprowadzić je ręcznie do środowiska produkcyjnego. Ale jak działają zatwierdzenia wydania?
Co to są zatwierdzenia wydania?
Zatwierdzenie wydania jest sposobem wstrzymania potoku do momentu zaakceptowania lub odrzucenia wydania przez osobę zatwierdzającą. Aby zdefiniować przepływ pracy przy wydawaniu, możesz połączyć zatwierdzenia, warunki i wyzwalacze.
Jak pamiętasz, w artykule Tworzenie potoku wydania w usłudze Azure Pipelines zdefiniowano środowisko w konfiguracji potoku reprezentujące środowisko wdrażania. Oto przykład z istniejącego rurociągu:
- 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 przepływy pracy mogą być wdrażane na tym środowisku i jakie zatwierdzenia ręczne są potrzebne do awansowania wersji z jednego etapu do następnego.
W dalszej części tego modułu zdefiniujesz środowisko etapowe i przypiszesz sobie rolę osoby zatwierdzającej, aby podwyższyć poziom aplikacji internetowej Space Game ze środowiska Test na środowisko Staging.
Automatyzuj tak mało 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: Podoba mi się, jak możemy zdefiniować kryteria, które promują zmiany z jednego etapu do następnego. Zdefiniowaliśmy jednak pewne kryteria ręczne w naszym procesie. 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. Trzymajmy się tego planu na razie i zobaczmy, jak później możemy przyspieszyć system.
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 wysyłamy zmianę do GitHub. Ten krok odbywa się na etapie kompilacji.
- Podnieś artefakt kompilacji do etapu Dev. Ten krok odbywa się automatycznie, gdy etap kompilacji zakończy się pomyślnie, a zmiana jest w gałęzi release.
- Podwyższaj artefakt kompilacji do etapu testowego każdego ranka o godzinie 3:00. Do automatycznego promowania artefaktu kompilacji używamy zaplanowanego wyzwalacza.
- Promuj artefakt kompilacji do Staging po tym, jak Amita przetestuje i zatwierdzi kompilację. W celu promocji 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 pipeline'ie ma również swoje własne środowisko. Na przykład, gdy wdrażamy aplikację w środowisku Dev lub Test, środowisko aplikacji jest instancją usługi App Service.
Na koniec testujemy tylko jedną wersję naraz. Nigdy nie zmieniamy wersji w środku ścieżki wydawniczej. Używamy tej samej wersji na etapie deweloperskim , co na etapie testowym, a każda wersja ma własny numer wersji. Jeśli wydanie zostanie przerwane na jednym z etapów, naprawimy je i skompilujemy ponownie przy użyciu nowego numeru wersji. To nowe wydanie przechodzi następnie przez ciąg procesów od samego początku.
Kilka słów o jakości
Właśnie zobaczyłeś, jak zespół zaprojektował potok, który przenosi ich aplikację od początku do końca, od kompilacji do etapu testowego. Istotą tego procesu nie jest tylko ułatwienie im życia. Jest to zapewnienie jakości oprogramowania dostarczanego przez nich klientom.
Jak zmierzyć jakość procesu wydania? Nie można go zmierzyć 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 nieustannie kończą się niepowodzeniem w określonym punkcie przepływu, 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ć różnorodne sprawdzenia w pipeline'u. Na przykład można wykonywać różne typy testów, takie jak testy obciążeniowe i testy interfejsu użytkownika w trakcie działania pipeline'u.
Korzystanie z progu 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 i czy masz odpowiednie możliwości śledzenia?
Podczas przechodzenia przez tę ścieżkę szkoleniową zobaczysz wiele z tych technik w praktyce.
Na koniec, projektując proces wydania wysokiej jakości, zastanów się, jaką dokumentację lub informacje o wersji powinieneś dostarczyć 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, który jest aplikacją funkcji zawierającą 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.