Definiowanie zatwierdzeń i kontroli

Azure DevOps Services

Potok składa się z etapów. Autor potoku może kontrolować, czy etap powinien być uruchamiany, definiując warunki na etapie. Innym sposobem kontrolowania, czy i kiedy etap powinien zostać uruchomiony, jest zatwierdzanie i sprawdzanie.

Zatwierdzenia i inne kontrole nie są zdefiniowane w pliku yaml. Użytkownicy modyfikując plik yaml potoku nie mogą modyfikować testów wykonanych przed rozpoczęciem etapu. Administracja istratory zasobów zarządzają sprawdzaniem przy użyciu interfejsu internetowego usługi Azure Pipelines.

Potoki bazują na zasobach, takich jak środowiska, połączenia usług, pule agentów, grupy zmiennych i bezpieczne pliki. Sprawdza, czy właściciel zasobu może kontrolować, czy i kiedy etap w dowolnym potoku może zużywać zasób. Jako właściciel zasobu można zdefiniować kontrole, które muszą być spełnione przed rozpoczęciem etapu zużywania tego zasobu. Na przykład ręczna kontrola zatwierdzenia w środowisku gwarantuje, że wdrożenie w tym środowisku odbywa się tylko po sprawdzeniu wdrożonych zmian przez wyznaczonego użytkownika.

Etap może składać się z wielu zadań, a każde zadanie może zużywać kilka zasobów. Przed rozpoczęciem wykonywania etapu wszystkie testy wszystkich zasobów używanych na tym etapie muszą być spełnione. Usługa Azure Pipelines wstrzymuje wykonywanie potoku przed każdym etapem i czeka na ukończenie wszystkich oczekujących testów.

Istnieje pięć kategorii zatwierdzeń i kontroli, które są uruchamiane w kolejności, w której zostały utworzone w ramach każdej kategorii. Kontrole są ponownie oceniane na podstawie interwału ponawiania określonego w każdym sprawdzeniu. Jeśli wszystkie testy nie zostaną wykonane, dopóki nie zostanie określony limit czasu, ten etap nie zostanie wykonany. Jeśli którykolwiek z testów nie powiedzie się (na przykład jeśli odrzucisz zatwierdzenie w jednym z zasobów), ten etap nie zostanie wykonany. Można jednak ponowić próbę etapu w przypadku zatwierdzeń i sprawdzenia limitu czasu.

Testy statyczne są uruchamiane najpierw, a następnie uruchamiane wstępne sprawdzanie zatwierdzeń. Kategorie w kolejności to:

1. Testy statyczne: Kontrolka gałęzi, Wymagany szablon i Ocena artefaktu
2. Wstępne sprawdzanie zatwierdzeń
3. Testy dynamiczne: zatwierdzanie, wywoływanie funkcji platformy Azure, wywoływanie interfejsu API REST, godziny pracy, wykonywanie zapytań o alerty usługi Azure Monitor
4. Zatwierdzenia po sprawdzeniu
5. Blokada wyłączna

Możesz również zobaczyć kolejność wykonywania na karcie Zatwierdzenia i sprawdzania.

Ważne

Kontrole można skonfigurować w środowiskach, połączeniach usług, repozytoriach, grupach zmiennych, bezpiecznych plikach i pulach agentów.

Nie można określić połączeń usługi przez zmienną.

Zatwierdzenia

Możesz ręcznie kontrolować, kiedy etap powinien być uruchamiany przy użyciu zatwierdzania i sprawdzania. Ta kontrola jest często używana do kontrolowania wdrożeń w środowiskach produkcyjnych.

1. Zaloguj się do organizacji usługi Azure DevOps, a następnie przejdź do projektu.

2. Wybierz pozycję Środowiska potoków>, a następnie wybierz środowisko.

3. Wybierz kartę Zatwierdzenia i sprawdza, a następnie wybierz + znak, aby dodać nowe sprawdzenie.

   

4. Wybierz Zatwierdzenia, a następnie wybierz przycisk Dalej.

5. Dodaj użytkowników lub grupy jako wyznaczonych osób zatwierdzających, a w razie potrzeby podaj instrukcje dla osób zatwierdzających. Określ, czy chcesz zezwolić na zatwierdzanie własnych przebiegów lub ograniczyć je, i określ żądany limit czasu. Jeśli zatwierdzenia nie zostaną ukończone w ramach określonego limitu czasu, etap zostanie oznaczony jako pominięty.

6. Po zakończeniu wybierz pozycję Utwórz .

   

7. Po wyzwoleniu sprawdzania zatwierdzenia zostanie wyświetlone okno monitu, jak pokazano w poniższym przykładzie, w interfejsie użytkownika. To okno zawiera opcję odrzucania lub zatwierdzania przebiegu przez osoby zatwierdzające wraz z wszystkimi towarzyszącymi instrukcjami.

   

Lista użytkowników, którzy mogą przejrzeć zatwierdzenie, została naprawiona podczas uruchamiania zatwierdzeń i testów. Oznacza to, że zmiany na liście użytkowników i grup sprawdzania zatwierdzenia wykonane po sprawdzeniu rozpoczęcia wykonywania nie są pobierane.

Uwaga

Jeśli grupa jest wyznaczona jako osoba zatwierdzająca, tylko jeden użytkownik w grupie musi zatwierdzić, aby przebieg był kontynuowany.

Zatwierdzenia odroczone

Występują sytuacje, w których czas zatwierdzenia i godzina rozpoczęcia wdrożenia nie jest zgodna. Na przykład możesz poczekać na wdrożenie nowej wersji do czasu małego ruchu w godzinach wieczornych.

Aby rozwiązać ten scenariusz, możesz odroczyć zatwierdzenie i ustawić czas, w którym zatwierdzenie stanie się skuteczne.

1. Wybierz pozycję Odroczenie zatwierdzenia.

   

2. Ustaw czas zatwierdzania.

   

Zatwierdzenie zostanie wyświetlone w panelu Sprawdzanie jako wstępne zatwierdzenie. Zatwierdzenie będzie obowiązywać w określonym czasie.

Kontrolka gałęzi

Korzystając z kontroli gałęzi, możesz upewnić się, że wszystkie zasoby połączone z potokiem są kompilowane z dozwolonych gałęzi i że gałęzie mają włączoną ochronę. Ta kontrola pomaga w kontrolowaniu gotowości wydania i jakości wdrożeń. Jeśli wiele zasobów jest połączonych z potokiem, źródło wszystkich zasobów jest weryfikowane. Jeśli połączono inny potok, gałąź konkretnego przebiegu, zostanie zweryfikowana pod kątem ochrony.

Aby zdefiniować kontrolę gałęzi:

1. W projekcie usługi Azure DevOps przejdź do zasobu (na przykład środowiska), który musi być chroniony.

2. Przejdź do Zatwierdzenia i sprawdź, czy zasób jest sprawdzany.

3. Wybierz sprawdzanie kontrolki Gałąź i podaj rozdzieloną przecinkami listę dozwolonych gałęzi. Możesz określić, czy gałąź powinna mieć włączoną ochronę. Można również zdefiniować zachowanie stanu sprawdzania wielkości liter dla jednej z gałęzi, które nie są znane.

   

W czasie wykonywania sprawdzanie weryfikuje gałęzie dla wszystkich połączonych zasobów w przebiegu względem listy dozwolonych. Jeśli którakolwiek z gałęzi nie jest zgodna z kryteriami, sprawdzanie zakończy się niepowodzeniem, a etap zostanie oznaczony jako niepowodzenie.

Uwaga

Sprawdzanie wymaga, aby nazwy gałęzi są w pełni kwalifikowane. Upewnij się, że format nazwy gałęzi to refs/heads/<branch name>

Godziny pracy

Jeśli chcesz, aby wszystkie wdrożenia w danym środowisku miały miejsce tylko w określonym przedziale czasu, sprawdzanie godzin pracy jest idealnym rozwiązaniem. Po uruchomieniu potoku wykonanie etapu, który używa zasobu, czeka na godziny pracy. Jeśli masz wiele przebiegów wykonywanych jednocześnie, każda z nich jest niezależnie weryfikowana. Na początku godzin pracy sprawdzanie jest oznaczane pomyślnie dla wszystkich przebiegów.

Jeśli wykonanie etapu nie zostało rozpoczęte pod koniec godzin pracy (wstrzymane przez inne sprawdzanie), zatwierdzenie godzin pracy zostanie automatycznie wycofane i ponownej oceny zaplanowano na następny dzień. Sprawdzanie kończy się niepowodzeniem, jeśli wykonanie etapu nie rozpoczyna się w przedziale czasu określonym dla sprawdzenia, a etap jest oznaczony jako niepowodzenie.

Wywoływanie funkcji platformy Azure

Azure Functions to bezserwerowa platforma obliczeniowa oferowana przez platformę Azure. Za pomocą usługi Azure Functions można uruchamiać małe fragmenty kodu (nazywane "funkcjami") bez martwienia się o infrastrukturę aplikacji. Biorąc pod uwagę wysoką elastyczność, funkcje platformy Azure zapewniają doskonały sposób tworzenia własnych testów. Należy uwzględnić logikę funkcji zaewidencjonowania na platformie Azure, tak aby każde wykonanie było wyzwalane na żądanie HTTP, ma krótki czas wykonywania i zwraca odpowiedź. Podczas definiowania sprawdzania można przeanalizować treść odpowiedzi, aby wywnioskować, czy sprawdzanie zakończyło się pomyślnie. Ocenę można okresowo powtarzać przy użyciu ustawienia Czas między ocenami w opcjach sterowania. Dowiedz się więcej

Jeśli sprawdzanie nie powiedzie się w ramach skonfigurowanego limitu czasu, skojarzony etap zostanie pominięty. Etapy w zależności od tego są również pomijane. Aby uzyskać więcej informacji, zobacz zadanie Aplikacja funkcji platformy Azure.

Uwaga

Zmienne potoku zdefiniowane przez użytkownika są dostępne do sprawdzenia rozpoczynającego się od przebiegu 215.

Dowiedz się więcej na temat zalecanego sposobu używania funkcji wywoływania funkcji platformy Azure. Sprawdzanie musi być zgodne z określonymi regułami w zależności od ich trybu i liczby ponownych prób.

Wywołaj interfejs API REST

Wywołanie sprawdzania interfejsu API REST umożliwia integrację z dowolnymi istniejącymi usługami. Okresowo wykonaj wywołanie interfejsu API REST i kontynuuj, jeśli zwraca pomyślną odpowiedź. Dowiedz się więcej

Ocenę można okresowo powtarzać przy użyciu ustawienia Czas między ocenami w opcjach sterowania. Jeśli sprawdzanie nie powiedzie się w ramach skonfigurowanego limitu czasu, skojarzony etap zostanie pominięty. Etapy w zależności od tego są również pomijane. Aby uzyskać więcej informacji, zobacz Wywoływanie zadania interfejsu API REST.

Uwaga

Zmienne potoku zdefiniowane przez użytkownika są dostępne do sprawdzenia rozpoczynającego się od przebiegu 215.

Przeczytaj więcej na temat zalecanego sposobu używania sprawdzania interfejsu API REST.

Wykonywanie zapytań dotyczących alertów usługi Azure Monitor

Usługa Azure Monitor oferuje wizualizacje, zapytania, routing, alerty, autoskalowanie i automatyzację danych z infrastruktury platformy Azure i poszczególnych zasobów platformy Azure. Alerty to standardowy sposób wykrywania problemów z kondycją infrastruktury lub aplikacji i podejmowanie działań naprawczych. Wdrożenia kanary i etapowe wdrożenia to typowe strategie wdrażania używane do obniżenia ryzyka regresji w krytycznych aplikacjach. Po wdrożeniu na etapie (zestawie klientów) aplikacja jest obserwowana przez pewien czas. Kondycja aplikacji po wdrożeniu jest używana do decydowania, czy aktualizacja ma zostać zastosowana do następnego etapu, czy nie.

Wykonywanie zapytań dotyczących alertów usługi Azure Monitor pomaga obserwować usługę Azure Monitor i upewnić się, że po wdrożeniu nie są zgłaszane żadne alerty. Sprawdzanie powiedzie się, jeśli w momencie oceny nie są aktywowane żadne reguły alertów. Dowiedz się więcej

Ocena jest powtarzana po ustawieniu Czas między ocenami w opcjach sterowania. Sprawdzanie nie powiedzie się, jeśli etap nie rozpoczął wykonywania w określonym przedziale czasu .

Wymagany szablon

Korzystając z wymaganego sprawdzania szablonu, możesz wymusić potoki, aby używać określonego szablonu YAML. Po zakończeniu tego sprawdzania potok zakończy się niepowodzeniem, jeśli nie zostanie on rozszerzony z szablonu, do których odwołuje się odwołanie.

Aby zdefiniować wymagane zatwierdzenie szablonu:

1. W projekcie usługi Azure DevOps przejdź do połączenia usługi, które chcesz ograniczyć.

2. Otwórz Zatwierdzenia i sprawdź w menu obok pozycji Edytuj.

3. W menu Dodaj pierwszy znacznik wyboru wybierz pozycję Wymagany szablon.

4. Wprowadź szczegółowe informacje na temat sposobu uzyskiwania do wymaganego pliku szablonu.

   • Typ repozytorium: lokalizacja repozytorium (GitHub, Azure lub Bitbucket).
   • Repozytorium: nazwa repozytorium zawierającego szablon.
   • Odwołanie: gałąź lub tag wymaganego szablonu.
   • Ścieżka do wymaganego szablonu: nazwa szablonu.

Możesz mieć wiele wymaganych szablonów dla tego samego połączenia usługi. W tym przykładzie wymagany szablon to production_template.yaml.

Wyłączanie sprawdzania

Podczas debugowania sprawdzania można tymczasowo wyłączyć, a następnie ponownie ją włączyć. Aby wyłączyć lub włączyć sprawdzanie:

1. W projekcie usługi Azure DevOps przejdź do zasobu z sprawdzeniem.

2. Otwórz kartę Zatwierdzenia i kontrole.

3. W menu kontekstowym wybierz pozycję Wyłącz lub Włącz.

   

Pomijanie sprawdzania

W niektórych okolicznościach, takich jak wdrożenie poprawek, może być konieczne obejście sprawdzania. Sprawdzanie można pominąć tylko wtedy, gdy masz uprawnienia administratora dla zasobu, w którym jest zdefiniowana kontrola.

Aby pominąć zatwierdzenie, godziny pracy, wywołać funkcję platformy Azure lub wywołać sprawdzanie interfejsu API REST, wybierz pozycję Pomiń sprawdzanie , kiedy zasób oczekuje na przegląd. Oto przykład pomijania kontroli godzin pracy.

Po obejściu sprawdzania zobaczysz, kto pominął sprawdzanie w panelu kontroli.

Ocena artefaktu

Artefakty, które mają być wdrażane w środowisku, można ocenić pod kątem zasad niestandardowych.

Uwaga

Obecnie działa to tylko z artefaktami obrazu kontenera

Aby zdefiniować niestandardową ocenę zasad dla artefaktów, wykonaj poniższe kroki.

1. W projekcie usługi Azure DevOps Services przejdź do środowiska, które musi być chronione. Dowiedz się więcej o tworzeniu środowiska.

   

2. Przejdź do Zatwierdzenia i sprawdź środowisko.

   

3. Wybierz pozycję Oceń artefakt.

   

4. Wklej definicję zasad i wybierz pozycję Zapisz. Zobacz więcej na temat pisania definicji zasad.

   

Po uruchomieniu potoku wykonanie tego uruchomienia jest wstrzymywane przed wejściem do etapu korzystającego ze środowiska. Określone zasady są oceniane względem dostępnych metadanych obrazu. Sprawdzanie jest sprawdzane, gdy zasady zakończyły się pomyślnie i nie powiodły się w przeciwnym razie. Etap jest oznaczony jako niepowodzenie, jeśli sprawdzanie nie powiedzie się.

Wynik pozytywny

Pełne dzienniki kontroli zasad można również wyświetlić w widoku potoku.

Nie działa

Pełne dzienniki kontroli zasad można również wyświetlić w widoku potoku.

Blokada wyłączna

Kontrola blokady na wyłączność umożliwia kontynuowanie tylko jednego uruchomienia z potoku. Wszystkie etapy we wszystkich uruchomieniach tego potoku, które używają zasobu, są wstrzymane. Po zakończeniu etapu korzystania z blokady inny etap może przejść do użycia zasobu. Ponadto tylko jeden etap może być kontynuowany.

Zachowanie innych etapów, które próbują podjąć blokadę, jest konfigurowane przez lockBehavior wartość skonfigurowaną w pliku YAML dla potoku.

• runLatest — Tylko najnowszy przebieg uzyskuje blokadę zasobu. runLatest jest wartością domyślną, jeśli nie lockBehavior jest określona.
• sequential — Wszystkie przebiegi uzyskują blokadę sekwencyjnie do chronionego zasobu.

Aby użyć wyłącznej kontroli blokady sequential we wdrożeniach lub runLatest, wykonaj następujące kroki:

1. Włącz wyłączne sprawdzanie blokady w środowisku (lub inny chroniony zasób).
2. W pliku YAML potoku określ właściwość o nazwie lockBehavior. Można to określić dla całego potoku lub dla danego etapu:

Ustaw na etapie:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Ustaw w potoku:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Jeśli nie określisz lockBehaviorwartości , zostanie użyta wartość domyślna runLatest .

Zarządzanie zmianami usługi ServiceNow

Ta kontrola wymaga zainstalowania rozszerzenia serviceNow Change Management z witryny Marketplace

Sprawdzanie zarządzania zmianami usługi ServiceNow umożliwia integrację procesu zarządzania zmianami usługi ServiceNow w potokach. Dodając sprawdzenie, nowe żądanie zmiany w usłudze ServiceNow można utworzyć automatycznie na początku etapu. Potok czeka na zakończenie procesu zmiany przed rozpoczęciem etapu. Więcej informacji można znaleźć tutaj.

Wiele Zatwierdzenia i kontrole

Etap może składać się z wielu zadań, a każde zadanie może zużywać kilka zasobów. Przed rozpoczęciem wykonywania etapu wszystkie testy wszystkich zasobów używanych na tym etapie muszą być spełnione. Usługa Azure Pipelines wstrzymuje wykonywanie potoku przed każdym etapem i czeka na ukończenie wszystkich oczekujących testów.

Jedna ostateczna negatywna decyzja powoduje, że potok zostanie odrzucony, a etap zakończy się niepowodzeniem. Decyzje wszystkich zatwierdzeń i kontroli z wyjątkiem wywołania funkcji platformy Azure/interfejsu API REST i blokady wyłączności są ostateczne. Możesz ponownie uruchomić pomyślnie wywołanie funkcji platformy Azure/kontroli interfejsu API REST.

W przypadku korzystania z funkcji wywoływania funkcji platformy Azure/interfejsu API REST w zalecany sposób decyzje dotyczące dostępu są również ostateczne.

Po określeniu czasu między ocenami dla wywołania funkcji platformy Azure/ interfejsu API REST sprawdź, czy nie ma wartości zero, decyzja sprawdzania nie jest ostateczna. Ten scenariusz warto zbadać.

Przyjrzyjmy się przykładowi. Wyobraź sobie, że potok YAML ma etap korzystający z połączenia z usługą. To połączenie z usługą ma skonfigurowane dwa testy:

1. Sprawdzanie asynchroniczne o nazwie Zatwierdzenie zewnętrzne przyznane, które weryfikuje, czy udzielono zatwierdzenia zewnętrznego i jest skonfigurowane w zalecany sposób.
2. Synchroniczna kontrola o nazwie Przyczyna wdrożenia Prawidłowa, która sprawdza, czy przyczyna wdrożenia jest prawidłowa i dla której ustawiono czas między ocenami na 7 minut.

Możliwe wykonanie kontroli jest pokazane na poniższym diagramie.

W tym wykonaniu:

• Oba kontrole, zatwierdzenie zewnętrzne przyznane i przyczyna wdrożenia prawidłowe, są wywoływane w tym samym czasie. Przyczyna wdrożenia — prawidłowa przyczyna nie powiedzie się natychmiast, ale ponieważ zatwierdzenie zewnętrzne jest oczekujące, zostanie ponowiona.
• W chwili 7 . Przyczyna wdrożenia jest ponawiana i tym razem jest przekazywana.
• W 15 . minucie udzielono zatwierdzenia zewnętrznego wywołania z powrotem do usługi Azure Pipelines z pomyślną decyzją. Teraz oba testy są przekazywane, więc potok może kontynuować wdrażanie etapu.

Przyjrzyjmy się innemu przykładowi z udziałem dwóch synchronicznych testów. Załóżmy, że potok YAML ma etap korzystający z połączenia z usługą. To połączenie z usługą ma skonfigurowane dwa testy:

1. Synchroniczna kontrola o nazwie Sync Check 1, dla której ustawiono wartość Czas między ocenami na 5 minut.
2. Synchroniczne sprawdzanie o nazwie Sync Check 2, dla którego ustawiono czas między ocenami na 7 minut.

Możliwe wykonanie kontroli jest pokazane na poniższym diagramie.

W tym wykonaniu:

• Oba testy, Sprawdzanie synchronizacji 1 i Sync Check 2, są wywoływane w tym samym czasie. Sprawdzanie synchronizacji 1 kończy się pomyślnie, ale zostanie ponowiona, ponieważ sprawdzanie synchronizacji 2 kończy się niepowodzeniem.
• W 5. minucie sprawdzanie synchronizacji 1 jest ponawiane, ale kończy się niepowodzeniem, więc zostanie ponowiona.
• W 7 . minucie ponawiana jest ponowna kontrola synchronizacji 2 i kończy się powodzeniem. Decyzja o uchwaleniu jest ważna przez 7 minut. Jeśli sprawdzanie synchronizacji 1 nie przejdzie w tym interwale czasu, zostanie ponowiona kontrola synchronizacji 2 .
• W 10. minucie sprawdzanie synchronizacji 1 jest ponawiane, ale kończy się niepowodzeniem, więc zostanie ponowiona.
• W 14 . minucie sprawdzanie synchronizacji 2 jest ponawiane i kończy się powodzeniem. Decyzja o uchwaleniu jest ważna przez 7 minut. Jeśli sprawdzanie synchronizacji 1 nie przejdzie w tym interwale czasu, zostanie ponowiona kontrola synchronizacji 2 .
• W 15 . minucie sprawdzanie synchronizacji 1 jest ponawiane i kończy się powodzeniem. Teraz oba testy są przekazywane, więc potok może kontynuować wdrażanie etapu.

Przyjrzyjmy się przykładowi, który obejmuje zatwierdzenie i synchroniczne sprawdzanie. Wyobraź sobie, że skonfigurowano synchroniczne sprawdzanie i zatwierdzenie połączenia z usługą z czasem między ocenami 5 minut. Do momentu zatwierdzenia sprawdzanie jest uruchamiane co 5 minut, niezależnie od decyzji.

Często zadawane pytania

Zdefiniowane kontrole nie zostały uruchomione. Co się stało?

Ocena testów rozpoczyna się po spełnieniu warunków etapu. Należy potwierdzić uruchomienie etapu uruchomionego po dodaniu kontroli do zasobu i że zasób jest używany na etapie.

Jak mogę użyć kontroli planowania etapu?

Korzystając z sprawdzania godzin pracy, możesz kontrolować czas rozpoczęcia wykonywania etapu. Możesz osiągnąć takie samo zachowanie, jak wstępnie zdefiniowany harmonogram na etapie w wersjach projektanta.

Jak mogę podjąć zatwierdzenia z wyprzedzeniem dla etapu zaplanowanego do uruchomienia w przyszłości?

Ten scenariusz można włączyć.

1. Sprawdzanie godzin pracy umożliwia zaplanowanie wykonywania wszystkich etapów wdrażania w zasobie między przedziałem czasu
2. Po skonfigurowaniu zatwierdzeń w tym samym zasobie etap będzie czekał na zatwierdzenia przed rozpoczęciem.
3. Możesz skonfigurować obie kontrole zasobu. Etap będzie czekał na zatwierdzenia i godziny pracy. Zostanie ono uruchomione w następnym zaplanowanym oknie po zakończeniu zatwierdzania.

Czy mogę poczekać na zakończenie skanowania zabezpieczeń wdrożonego artefaktu?

Aby poczekać na zakończenie skanowania zabezpieczeń wdrożonego artefaktu, należy użyć zewnętrznej usługi skanowania, takiej jak AquaScan. Wdrażany artefakt musi zostać przekazany w lokalizacji dostępnej dla usługi skanowania przed rozpoczęciem testów i można go zidentyfikować przy użyciu wstępnie zdefiniowanych zmiennych. Korzystając z sprawdzania wywołania interfejsu API REST, możesz dodać kontrolę, aby zaczekać na interfejs API w usłudze zabezpieczeń i przekazać identyfikator artefaktu jako dane wejściowe.

Jak mogę używać zmiennych wyjściowych z poprzednich etapów kontroli?

Domyślnie tylko wstępnie zdefiniowane zmienne są dostępne do kontroli. Aby uzyskać dostęp do innych zmiennych, możesz użyć połączonej grupy zmiennych. Zmienną wyjściową z poprzedniego etapu można zapisać w grupie zmiennych i uzyskać do niej dostęp w ramach kontroli.

Dowiedz się więcej

• Wywoływanie kontroli funkcji platformy Azure/interfejsu API REST
• Zatwierdzenia i sprawdza interfejs API REST
• interfejs API REST zapytań Zatwierdzenia