Wywoływanie kontroli funkcji platformy Azure/interfejsu API REST

  • Artykuł

Sprawdzanie wywołania funkcji platformy Azure/interfejsu API REST umożliwia pisanie kodu w celu określenia, czy określony etap potoku może uzyskać dostęp do chronionego zasobu, czy nie. Te testy mogą być uruchamiane w dwóch trybach:

  • Asynchroniczne (zalecane): tryb wypychania, w którym usługa Azure DevOps oczekuje na implementację funkcji platformy Azure/interfejsu API REST w celu wywołania z powrotem do usługi Azure DevOps z decyzją dotyczącą dostępu etapowego
  • Synchroniczne: tryb sondowania, w którym usługa Azure DevOps okresowo wywołuje interfejs API REST/funkcji platformy Azure, aby uzyskać decyzję o dostępie do etapu

W pozostałej części tego przewodnika odwołujemy się do funkcji platformy Azure /sprawdzania interfejsu API REST po prostu jako sprawdzania.

Zalecanym sposobem korzystania z kontroli jest tryb asynchroniczny. Ten tryb zapewnia najwyższy poziom kontroli nad logiką sprawdzania, ułatwia rozumowanie stanu systemu i oddzielenie usługi Azure Pipelines od implementacji sprawdzania, zapewniając najlepszą skalowalność. Wszystkie synchroniczne kontrole można zaimplementować przy użyciu trybu kontroli asynchronicznej.

Kontrole asynchroniczne

W trybie asynchronicznym usługa Azure DevOps wykonuje wywołanie funkcji platformy Azure/interfejsu API REST i oczekuje na wywołanie zwrotne z decyzją o dostępie do zasobów. Nie ma otwartego połączenia HTTP między usługą Azure DevOps i implementacją sprawdzania w okresie oczekiwania.

W pozostałej części tej sekcji omówiono kontrole funkcji platformy Azure, ale jeśli nie określono inaczej, wskazówki dotyczą również sprawdzania interfejsu API REST wywołania.

Zalecany tryb asynchroniczny ma dwa kroki komunikacji:

  1. Dostarczanie ładunku kontrolnego. Usługa Azure Pipelines wykonuje wywołanie HTTP do funkcji platformy Azure/interfejsu API REST tylko w celu dostarczenia ładunku kontrolnego, a nie otrzymania decyzji na miejscu. Funkcja powinna po prostu potwierdzić otrzymanie informacji i zakończyć połączenie HTTP z usługą Azure DevOps. Implementacja sprawdzania powinna przetworzyć żądanie HTTP w ciągu 3 sekund.
  2. Podejmowanie decyzji o dostępie za pośrednictwem wywołania zwrotnego. Sprawdzanie powinno być uruchamiane asynchronicznie, ocenianie warunku niezbędnego dla potoku w celu uzyskania dostępu do chronionego zasobu (ewentualnie przeprowadzania wielu ocen w różnych punktach w czasie). Po podjęciu ostatecznej decyzji funkcja platformy Azure wykonuje wywołanie REST PROTOKOŁU HTTP do usługi Azure DevOps w celu przekazania decyzji. W dowolnym momencie powinno istnieć jedno otwarte połączenie HTTP między usługą Azure DevOps i implementacją sprawdzania. Dzięki temu zasoby są zapisywane zarówno po stronie funkcji platformy Azure, jak i po stronie usługi Azure Pipelines.

Jeśli sprawdzanie przebiegnie pomyślnie, potok może uzyskać dostęp do chronionego zasobu i wdrożenia etapu. Jeśli sprawdzanie zakończy się niepowodzeniem, etap zakończy się niepowodzeniem. Jeśli istnieje wiele kontroli w jednym etapie, wszystkie elementy muszą przejść przed uzyskaniem dostępu do chronionych zasobów, ale pojedynczy błąd wystarczy, aby zakończyć etap.

Zalecana implementacja trybu asynchronicznego dla pojedynczego sprawdzania funkcji platformy Azure jest przedstawiona na poniższym diagramie.

Diagram that shows the recommended implementation of the async mode for a single Azure Function check.

Kroki opisane na diagramie to:

  1. Sprawdź dostarczanie. Usługa Azure Pipelines przygotowuje się do wdrożenia etapu potoku i wymaga dostępu do chronionego zasobu. Wywołuje ona odpowiednie sprawdzanie funkcji platformy Azure i oczekuje potwierdzenia potwierdzenia potwierdzenia przez wywołanie kończące się kodem stanu HTTP 200. Wdrażanie etapu jest wstrzymane w oczekiwaniu na decyzję.
  2. Sprawdź ocenę. Ten krok odbywa się wewnątrz implementacji funkcji platformy Azure, która działa na własnych zasobach platformy Azure i kodzie, który jest całkowicie pod kontrolą. Zalecamy wykonanie następujących czynności:
    • 2.1 Uruchamianie zadania asynchronicznego i zwracanie kodu stanu HTTP200
    • 2.2 Wprowadź pętlę wewnętrzną, w której może wykonywać wiele ocen warunków
    • 2.3 Ocena warunków dostępu
    • 2.4 Jeśli nie może ona podjąć ostatecznej decyzji, ponownie przeszacuj warunki dla późniejszego punktu, przejdź do kroku 2.3
  3. Komunikacja decyzyjna. Funkcja platformy Azure wywołuje ponownie usługę Azure Pipelines z decyzją o dostępie. Wdrażanie etapu może kontynuować

W przypadku korzystania z zalecanej implementacji na stronie szczegółów przebiegu potoku jest wyświetlany najnowszy dziennik sprawdzania.

Screenshot of pipeline run details with check information.

W panelu konfiguracji funkcji platformy Azure/interfejsu API REST upewnij się, że:

  • Wybrane wywołanie zwrotne dla zdarzenia ukończenia
  • Ustaw czas między ocenami (w minutach) na 0

Ustawienie wartości Czas między ocenami a wartością niezerową oznacza, że decyzja kontrolna (powodzenie/niepowodzenie) nie jest ostateczna. Sprawdzanie jest ponownie oceniane, dopóki wszystkie inne Zatwierdzenia i kontrole nie osiągną stanu końcowego.

Przekazywanie informacji o przebiegu potoku do sprawdzania

Podczas konfigurowania sprawdzania można określić informacje o przebiegu potoku, które chcesz wysłać do sprawdzenia. Co najmniej należy wysłać:

  • "PlanUrl": "$(system.CollectionUri)"
  • "ProjectId": "$(system.TeamProjectId)"
  • "HubName": "$(system.HostType)"
  • "PlanId": "$(system.PlanId)"
  • "JobId": "$(system.JobId)"
  • "TaskInstanceId": "$(system.TaskInstanceId)"
  • "AuthToken": "$(system.AccessToken)"

Te pary klucz-wartość są ustawiane domyślnie w Headers wywołaniu REST wykonanym przez usługę Azure Pipelines.

Należy użyć AuthToken polecenia , aby wykonać wywołania do usługi Azure DevOps, na przykład podczas sprawdzania wywołań z powrotem z decyzją.

Wywoływanie metodyki Azure DevOps

Aby podjąć decyzję, może być konieczne sprawdzenie informacji o bieżącym uruchomieniu potoku, którego nie można przekazać do sprawdzania, więc należy go pobrać. Wyobraź sobie, że sprawdzanie sprawdza, czy uruchomienie potoku wykonało określone zadanie, na przykład zadanie analizy statycznej. Sprawdzenie musi wywołać usługę Azure DevOps i pobrać listę już wykonanych zadań.

Aby wywołać usługę Azure DevOps, zalecamy użycie tokenu dostępu do zadania wystawionego na potrzeby wykonywania sprawdzania zamiast osobistego tokenu dostępu (PAT). Token jest już udostępniany do sprawdzania domyślnie w nagłówku AuthToken .

W porównaniu z dostawcami dostępu do zadań token dostępu do zadań jest mniej podatny na ograniczanie przepustowości, nie wymaga ręcznego odświeżania i nie jest powiązany z kontem osobistym. Token jest ważny przez 48 godzin.

Używanie tokenu dostępu do zadania wszystkich, ale usuwa problemy z ograniczaniem przepływności interfejsu API REST usługi Azure DevOps. W przypadku korzystania z tokenu pat używasz tego samego identyfikatora PAT dla wszystkich przebiegów potoku. Jeśli uruchamiasz dużą liczbę potoków, token dostępu zostanie ograniczony. Jest to mniej problem z tokenem dostępu do zadania, ponieważ dla każdego wykonania sprawdzania jest generowany nowy token.

Token jest wystawiany dla tożsamości kompilacji używanej do uruchamiania potoku, na przykład usługi kompilacji FabrikamFiberChat (FabrikamFiber). Innymi słowy, token może służyć do uzyskiwania dostępu do tych samych repozytoriów lub przebiegów potoku, które może obsługiwać potok hosta. Jeśli włączono opcję Ochrona dostępu do repozytoriów w potokach YAML, jego zakres jest dodatkowo ograniczony tylko do repozytoriów, do których odwołuje się przebieg potoku.

Jeśli sprawdzanie wymaga dostępu do zasobów powiązanych z potokami, na przykład scenariuszy użytkowników usługi Boards, należy przyznać takie uprawnienia tożsamościom kompilacji potoków. Jeśli sprawdzanie można wyzwolić z wielu projektów, upewnij się, że wszystkie potoki we wszystkich projektach mają dostęp do wymaganych zasobów.

Wysyłanie decyzji z powrotem do usługi Azure DevOps

Implementacja sprawdzania musi używać wywołania interfejsu API REST post event , aby przekazać decyzję z powrotem do usługi Azure Pipelines. Upewnij się, że określono następujące właściwości:

  • Headers: Basic: {AuthToken}
  • Body:
{
    "name": "TaskCompleted",
    "taskId": "{TaskInstanceId}",
    "jobId": "{JobId}",
    "result": "succeeded|failed"
}

Wysyłanie aktualizacji stanu do usługi Azure DevOps z kontroli

Aktualizacje stanu dla użytkowników usługi Azure Pipelines można udostępniać z poziomu testów przy użyciu interfejsów API REST usługi Azure Pipelines. Ta funkcja jest przydatna, na przykład jeśli chcesz poinformować użytkowników, że sprawdzanie czeka na akcję zewnętrzną, np. ktoś musi zatwierdzić bilet usługi ServiceNow.

Kroki wysyłania aktualizacji stanu to:

  1. Tworzenie dziennika zadań
  2. Dołączanie do dziennika zadań
  3. Aktualizowanie rekordu osi czasu

Wszystkie wywołania interfejsu API REST muszą być uwierzytelnione.

Przykłady

Podstawowe sprawdzanie funkcji platformy Azure

W tym podstawowym przykładzie funkcja platformy Azure sprawdza, czy uruchomienie potoku wywołującego wykonało zadanie przed udzieleniem CmdLine mu dostępu do chronionego zasobu.

Funkcja platformy Azure zawiera następujące kroki:

  1. Potwierdza potwierdzenie otrzymania ładunku kontrolnego
  2. Wysyła aktualizację stanu do usługi Azure Pipelines, która została uruchomiona
  3. Używa {AuthToken} metody , aby wykonać wywołanie zwrotne w usłudze Azure Pipelines w celu pobrania wpisu oś czasu przebiegu potoku
  4. Sprawdza, czy oś czasu zawiera zadanie z "id": "D9BAFED4-0B18-4F58-968D-86655B4D2CE9" (identyfikator CmdLine zadania)
  5. Wysyła aktualizację stanu z wynikiem wyszukiwania
  6. Wysyła decyzję kontrolną do usługi Azure Pipelines

Ten przykład można pobrać z usługi GitHub.

Aby użyć tej funkcji platformy Azure, należy określić następujące Headers elementy podczas konfigurowania sprawdzania:

{
    "Content-Type":"application/json", 
    "PlanUrl": "$(system.CollectionUri)", 
    "ProjectId": "$(system.TeamProjectId)", 
    "HubName": "$(system.HostType)", 
    "PlanId": "$(system.PlanId)", 
    "JobId": "$(system.JobId)", 
    "TimelineId": "$(system.TimelineId)", 
    "TaskInstanceId": "$(system.TaskInstanceId)", 
    "AuthToken": "$(system.AccessToken)",
    "BuildId": "$(build.BuildId)"
}

Zaawansowane sprawdzanie funkcji platformy Azure

W tym zaawansowanym przykładzie funkcja platformy Azure sprawdza, czy element roboczy usługi Azure Boards, do którego odwołuje się komunikat zatwierdzenia, który wyzwolił przebieg potoku, jest w prawidłowym stanie.

Funkcja platformy Azure zawiera następujące kroki:

  1. Potwierdza potwierdzenie otrzymania ładunku kontrolnego
  2. Wysyła aktualizację stanu do usługi Azure Pipelines, która została uruchomiona
  3. Używa {AuthToken} metody do tworzenia wywołania zwrotnego w usłudze Azure Pipelines w celu pobrania stanu elementu roboczego usługi Azure Boards, do którego odwołuje się komunikat zatwierdzenia, który wyzwolił uruchomienie potoku
  4. Sprawdza, czy element roboczy jest w Completed stanie
  5. Wysyła aktualizację stanu z wynikiem sprawdzenia
  6. Jeśli element roboczy nie znajduje się w Completed stanie, zmienia kolejną ocenę w ciągu 1 minuty
  7. Gdy element roboczy jest w prawidłowym stanie, wysyła pozytywną decyzję do usługi Azure Pipelines

Ten przykład można pobrać z usługi GitHub.

Aby użyć tej funkcji platformy Azure, należy określić następujące Headers elementy podczas konfigurowania sprawdzania:

{
    "Content-Type":"application/json", 
    "PlanUrl": "$(system.CollectionUri)", 
    "ProjectId": "$(system.TeamProjectId)", 
    "HubName": "$(system.HostType)", 
    "PlanId": "$(system.PlanId)", 
    "JobId": "$(system.JobId)", 
    "TimelineId": "$(system.TimelineId)", 
    "TaskInstanceId": "$(system.TaskInstanceId)", 
    "AuthToken": "$(system.AccessToken)",
    "BuildId": "$(build.BuildId)"
}

Obsługa błędów

Obecnie usługa Azure Pipelines ocenia pojedyncze wystąpienie sprawdzania co najwyżej 2000 razy.

Jeśli sprawdzanie nie wywołuje z powrotem do usługi Azure Pipelines w ramach skonfigurowanego limitu czasu, skojarzony etap zostanie pominięty. Etapy w zależności od tego są również pomijane.

Testy synchroniczne

W trybie synchronicznym usługa Azure DevOps wykonuje wywołanie funkcji platformy Azure / interfejsu API REST, aby uzyskać natychmiastową decyzję, czy dostęp do chronionego zasobu jest dozwolony, czy nie.

Implementacja trybu synchronizacji dla pojedynczej funkcji platformy Azure jest przedstawiona na poniższym diagramie.

Diagram that shows the implementation of the sync mode for a single Azure Function check.

Kroki to:

  1. Usługa Azure Pipelines przygotowuje się do wdrożenia etapu potoku i wymaga dostępu do chronionego zasobu
  2. Wchodzi w pętlę wewnętrzną, w której:
  • 2.1. Usługa Azure Pipelines wywołuje odpowiednie sprawdzanie funkcji platformy Azure i czeka na decyzję
  • 2.2. Funkcja platformy Azure ocenia warunki niezbędne do zezwolenia na dostęp i zwraca decyzję
  • 2.3. Jeśli treść odpowiedzi funkcji platformy Azure nie spełnia zdefiniowanych kryteriów powodzenia, a czas między ocenami jest inny niż zero, usługa Azure Pipelines ponownie wykonuje kolejną ocenę sprawdzania po upływie czasu między ocenami

Konfigurowanie kontroli synchronicznych

Aby użyć trybu synchronicznego dla funkcji platformy Azure/interfejsu API REST, w panelu konfiguracji sprawdź, czy:

  • Wybrana wartość ApiResponse dla zdarzenia ukończenia w obszarze Zaawansowane
  • Określono kryteria powodzenia, które definiują, kiedy należy przekazać kontrolę na podstawie treści odpowiedzi sprawdzania
  • Ustaw wartość Czas między ocenami na 0 w obszarze Opcje kontroli
  • Ustaw limit czasu na czas oczekiwania na pomyślne sprawdzenie. Jeśli nie ma pozytywnej decyzji i zostanie osiągnięty limit czasu, odpowiedni etap potoku zostanie pominięty

Ustawienie Czas między ocenami określa, jak długo decyzja sprawdzania jest prawidłowa. Wartość 0 oznacza, że decyzja jest ostateczna. Wartość niezerowa oznacza, że sprawdzanie zostanie ponowione po skonfigurowanym interwale, gdy jego decyzja jest ujemna. Gdy jest uruchomionych wiele Zatwierdzenia i kontrole, sprawdzanie jest ponawiane niezależnie od decyzji.

Maksymalna liczba ocen jest definiowana przez stosunek między wartościami Limit czasu i Czas między wartościami oceny. Zalecamy upewnienie się, że ten stosunek wynosi co najwyżej 10.

Przekazywanie informacji o przebiegu potoku do sprawdzania

Podczas konfigurowania sprawdzania można określić informacje o uruchomieniu potoku, które chcesz wysłać do funkcji platformy Azure/sprawdzania interfejsu API REST. Domyślnie usługa Azure Pipeline dodaje następujące informacje w Headers wywołaniu HTTP, które wykonuje.

  • "PlanUrl": "$(system.CollectionUri)"
  • "ProjectId": "$(system.TeamProjectId)"
  • "HubName": "$(system.HostType)"
  • "PlanId": "$(system.PlanId)"
  • "JobId": "$(system.JobId)"
  • "TaskInstanceId": "$(system.TaskInstanceId)"
  • "AuthToken": "$(system.AccessToken)"

Nie zalecamy wykonywania wywołań w usłudze Azure DevOps w trybie synchronicznym, ponieważ najprawdopodobniej spowoduje to, że sprawdzenie zajmie więcej niż 3 sekundy, więc sprawdzanie zakończy się niepowodzeniem.

Obsługa błędów

Obecnie usługa Azure Pipelines ocenia pojedyncze wystąpienie sprawdzania co najwyżej 2000 razy.

Kiedy należy używać kontroli asynchronicznych a synchronicznych

Przyjrzyjmy się przykładowym przypadkom użycia i zalecanym typem kontroli do użycia.

Informacje zewnętrzne muszą być poprawne

Załóżmy, że masz Połączenie usługi do zasobu produkcyjnego i chcesz mieć pewność, że dostęp do niego jest dozwolony tylko wtedy, gdy informacje w bilecie usługi ServiceNow są poprawne. W takim przypadku przepływ będzie następujący:

  • Dodajesz asynchroniczną kontrolę funkcji platformy Azure, która weryfikuje poprawność biletu usługi ServiceNow
  • Gdy potok, który chce używać Połączenie usługi, jest uruchamiany:
    • Usługa Azure Pipelines wywołuje funkcję check
    • Jeśli informacje są niepoprawne, sprawdzanie zwraca negatywną decyzję. Przyjmij ten wynik
    • Etap potoku kończy się niepowodzeniem
    • Informacje są aktualizowane w bilecie usługi ServiceNow
    • Ponowne uruchomienie etapu, który zakończył się niepowodzeniem
    • Sprawdzanie zostanie uruchomione ponownie i tym razem zakończy się powodzeniem
    • Przebieg potoku jest kontynuowany

Należy udzielić zatwierdzenia zewnętrznego

Załóżmy, że masz Połączenie usługi do zasobu produkcyjnego i chcesz mieć pewność, że dostęp do niego jest dozwolony tylko po zatwierdzeniu biletu usługi ServiceNow przez administratora. W takim przypadku przepływ będzie następujący:

  • Dodajesz asynchroniczną kontrolę funkcji platformy Azure, która weryfikuje zatwierdzenie biletu usługi ServiceNow
  • Gdy potok, który chce używać Połączenie usługi, jest uruchamiany:
    • Usługa Azure Pipelines wywołuje funkcję check.
    • Jeśli bilet usługi ServiceNow nie zostanie zatwierdzony, funkcja platformy Azure wysyła aktualizację do usługi Azure Pipelines i zmienia harmonogram, aby sprawdzić stan biletu w ciągu 15 minut
    • Po zatwierdzeniu biletu sprawdź wywołania z powrotem do usługi Azure Pipelines z pozytywną decyzją
    • Przebieg potoku jest kontynuowany

Proces programowania został następnie

Załóżmy, że masz Połączenie usługi do zasobu produkcyjnego i chcesz mieć pewność, że dostęp do niego jest dozwolony tylko wtedy, gdy pokrycie kodu przekracza 80%. W takim przypadku przepływ będzie następujący:

  • Potok jest zapisywany w taki sposób, że błędy etapu powodują niepowodzenie kompilacji
  • Dodasz asynchroniczny test funkcji platformy Azure, który weryfikuje pokrycie kodu dla skojarzonego przebiegu potoku
  • Gdy potok, który chce używać Połączenie usługi, jest uruchamiany:
    • Usługa Azure Pipelines wywołuje funkcję check
    • Jeśli warunek pokrycia kodu nie jest spełniony, sprawdzanie zwraca negatywną decyzję. Przyjmij ten wynik
    • Niepowodzenie sprawdzania powoduje niepowodzenie etapu, co powoduje niepowodzenie uruchomienia potoku
  • Zespół inżynierów dodaje niezbędne testy jednostkowe, aby osiągnąć pokrycie kodu w 80%
  • Zostanie wyzwolone nowe uruchomienie potoku, a tym razem sprawdzanie przebiegnie pomyślnie
    • Przebieg potoku jest kontynuowany

Kryteria wydajności muszą być spełnione

Załóżmy, że wdrażasz nowe wersje systemu w wielu krokach, począwszy od wdrożenia kanarowego. Chcesz mieć pewność, że wydajność wdrożenia kanarowego jest odpowiednia. W takim przypadku przepływ będzie następujący:

  • Dodawanie asynchronicznego sprawdzania funkcji platformy Azure
  • Gdy potok, który chce używać Połączenie usługi, jest uruchamiany:
    • Usługa Azure Pipelines wywołuje funkcję check
    • Sprawdzanie uruchamia monitor wydajności wdrożenia kanarowego
    • Sprawdzanie planuje wiele punktów kontrolnych oceny, aby zobaczyć, jak ewoluowała wydajność
    • Po uzyskaniu wystarczającej pewności co do wydajności wdrożenia kanarowego funkcja platformy Azure wywołuje ponownie usługę Azure Pipelines z pozytywną decyzją
    • Przebieg potoku jest kontynuowany

Przyczyna wdrożenia musi być prawidłowa

Załóżmy, że masz Połączenie usługi do zasobu środowiska produkcyjnego i chcesz mieć pewność, że dostęp do niego odbywa się tylko w przypadku ręcznie w kolejce kompilacji. W takim przypadku przepływ będzie następujący:

  • Dodajesz synchroniczny test funkcji platformy Azure, który sprawdza, czy Build.Reason dla uruchomienia potoku jestManual
  • Należy skonfigurować sprawdzanie funkcji platformy Azure w celu przekazania Build.Reason jej Headers
  • Należy ustawić czas sprawdzania między ocenami na 0, więc niepowodzenie lub przekazanie jest ostateczne i nie jest konieczna ponowna ocena
  • Gdy potok, który chce używać Połączenie usługi, jest uruchamiany:
    • Usługa Azure Pipelines wywołuje funkcję check
    • Jeśli przyczyna jest inna niż Manual, sprawdzanie zakończy się niepowodzeniem, a uruchomienie potoku zakończy się niepowodzeniem

Sprawdź zgodność

Wywołanie kontroli funkcji platformy Azure i interfejsu API REST obejmuje teraz reguły zgodne z zalecanym użyciem. Testy muszą być zgodne z tymi regułami w zależności od trybu i liczby ponownych prób:

  • Kontrole asynchroniczne (tryb wywołania zwrotnego): usługa Azure Pipelines nie ponawia próby sprawdzania asynchronicznego. Wynik należy podać asynchronicznie, gdy ocena jest ostateczna. Aby testy asynchroniczne zostały uznane za zgodne, przedział czasu między ocenami musi być 0.

  • Testy synchroniczne (tryb ApiResponse): maksymalna liczba ponownych prób dla sprawdzenia wynosi 10. Można ustawić na wiele sposobów. Można na przykład skonfigurować limit czasu na 20 i przedział czasu między ocenami a 2. Możesz też skonfigurować limit czasu na 100 i przedział czasu między ocenami a 10. Jeśli jednak skonfigurujesz limit czasu na 100 i ustawisz przedział czasu między ocenami 2, sprawdzanie nie będzie zgodne, ponieważ zostanie wyświetlony monit o 50 ponownych prób. Stosunek limitu czasu do przedziału czasu między ocenami powinien być mniejszy lub równy 10.

Dowiedz się więcej o wdrożeniu sprawdzania zgodności.

Wiele testów

Zanim usługa Azure Pipelines wdroży etap w przebiegu potoku, może być konieczne przekazanie wielu testów. Chroniony zasób może mieć skojarzona co najmniej jedną kontrolę. Etap może używać wielu chronionych zasobów. Usługa Azure Pipelines zbiera wszystkie kontrole skojarzone z każdym chronionym zasobem używanym na etapie i ocenia je jednocześnie.

Uruchomienie potoku może być wdrażane na etapie tylko wtedy, gdy wszystkie kontrole przechodzą w tym samym czasie. Jedna ostateczna negatywna decyzja powoduje, że potok zostanie odrzucony, a etap zakończy się niepowodzeniem.

Gdy używasz kontroli w zalecany sposób (asynchroniczny, ze stanami końcowymi) podejmuje ostateczne decyzje dotyczące dostępu i ułatwia zrozumienie stanu systemu.

Zapoznaj się z sekcją Wiele Zatwierdzenia i kontrole, aby zapoznać się z przykładami.

Dowiedz się więcej