Aufrufen von Azure-Funktions-/REST-API-Überprüfungen
Mit „Aufrufen von Azure-Funktions-/REST-API-Überprüfungen“ können Sie Code schreiben, um zu entscheiden, ob eine bestimmte Pipelinephase auf eine geschützte Ressource zugreifen darf. Diese Überprüfungen können in zwei Modi ausgeführt werden:
- Asynchron (empfohlen): Pushmodus, in dem Azure DevOps darauf wartet, dass die Azure-Funktions-/REST-API-Implementierung Azure DevOps mit einer Entscheidung für den Phasenzugriff zurückruft.
- Synchron: Abfragemodus, bei dem Azure DevOps periodisch die Azure-Funktion/REST-API aufruft, um eine Entscheidung über den Phasenzugriff abzurufen.
Im weiteren Verlauf dieses Leitfadens bezeichnen wir Azure-Funktions-/REST-API-Überprüfungen einfach als Überprüfungen.
Es wird empfohlen, die Überprüfungen im asynchronen Modus zu verwenden. Dieser Modus bietet Ihnen den höchsten Grad an Kontrolle über die Prüflogik, gestaltet es einfach, Rückschlüsse auf den Zustand des Systems zu ziehen und entkoppelt Azure Pipelines von Ihrer Implementierung der Überprüfungen, was die beste Skalierbarkeit bietet. Alle synchronen Überprüfungen können mithilfe des Modus für asynchrone Überprüfungen implementiert werden.
Asynchrone Überprüfungen
Im asynchronen Modus ruft Azure DevOps die Azure-Funktions-/REST-API-Überprüfung auf und erwartet einen Rückruf mit der Entscheidung hinsichtlich des Ressourcenzugriffs. Während der Wartezeit gibt es keine offene HTTP-Verbindung zwischen Azure DevOps und der Implementierung Ihrer Überprüfung.
Der Rest dieses Abschnitts befasst sich mit Azure-Funktionsüberprüfungen. Sofern nicht anders angegeben, gelten die Hinweise auch für „Aufrufen von REST-API-Überprüfungen“.
Empfohlene Implementierung von asynchronen Überprüfungen
Der empfohlene asynchrone Modus umfasst zwei Kommunikationsschritte:
- Übermitteln der Nutzdaten der Überprüfung. Azure Pipelines tätigt einen HTTP-Aufruf an Ihre Azure-Funktion/REST-API, um nur die Nutzdaten der Überprüfung zu übermitteln und nicht, um eine Entscheidung vor Ort zu erhalten. Ihre Funktion sollte lediglich den Empfang der Informationen bestätigen und die HTTP-Verbindung mit Azure DevOps beenden. Die Implementierung Ihrer Überprüfung sollte die HTTP-Anforderung innerhalb von drei Sekunden verarbeiten.
- Übermitteln der Zugriffsentscheidung über einen Rückruf. Ihre Überprüfung sollte asynchron ausgeführt werden und die Bedingung auswerten, die erforderlich ist, damit die Pipeline auf die geschützte Ressource zugreifen kann (möglicherweise werden mehrere Auswertungen zu verschiedenen Zeitpunkten durchgeführt). Sobald sie eine endgültige Entscheidung getroffen hat, tätigt Ihre Azure-Funktion einen HTTP-REST-Aufruf in Azure DevOps, um die Entscheidung mitzuteilen. Zu jedem Zeitpunkt sollte es eine einzelne offene HTTP-Verbindung zwischen Azure DevOps und der Implementierung Ihrer Überprüfung geben. Dadurch sparen Sie Ressourcen sowohl auf der Seite Ihrer Azure-Funktion als auch auf der Seite von Azure Pipelines.
Wenn die Überprüfung erfolgreich ist, erhält die Pipeline Zugriff auf eine geschützte Ressource und die Phasenbereitstellung kann fortgesetzt werden. Wenn bei der Überprüfung ein Fehler auftritt, schlägt die Phase fehl. Wenn es mehrere Überprüfungen in einer einzelnen Phase gibt, müssen alle bestanden werden, bevor der Zugriff auf geschützte Ressourcen erlaubt wird, aber ein einzelner Fehler reicht aus, damit die Phase fehlerhaft ist.
Die empfohlene Implementierung des asynchronen Modus für eine einzelne Azure-Funktionsüberprüfung ist im folgenden Diagramm dargestellt.
Die Schritte im Diagramm sind:
- Übermittlung überprüfen. Azure Pipelines bereitet die Bereitstellung einer Pipelinephase vor und benötigt Zugriff auf eine geschützte Ressource. Es ruft die entsprechende Azure-Funktionsüberprüfung auf und erwartet eine Empfangsbestätigung, indem der Aufruf mit einem HTTP 200-Statuscode endet. Die Phasenbereitstellung wird angehalten und eine Entscheidung ist ausstehend.
- Auswertung überprüfen. Dieser Schritt erfolgt innerhalb Ihrer Azure-Funktionsimplementierung, die auf Ihren eigenen Azure-Ressourcen ausgeführt wird und deren Code vollständig Ihrer Kontrolle unterliegt. Wir empfehlen, dass Ihre Azure-Funktion die folgenden Schritte befolgt:
- 2.1 Starten einer asynchronen Aufgabe und Rückgabe des HTTP-Statuscodes
200
- 2.2 Eingeben einer inneren Schleife, in der mehrere Bedingungsauswertungen erfolgen können.
- 2.3 Auswerten der Zugriffsbedingungen
- 2.4 Wenn keine endgültige Entscheidung getroffen werden kann, planen Sie eine erneute Auswertung der Bedingungen für einen späteren Zeitpunkt und wechseln Sie dann zu Schritt 2.3
- 2.1 Starten einer asynchronen Aufgabe und Rückgabe des HTTP-Statuscodes
- Kommunikation von Entscheidungen. Die Azure-Funktion ruft Azure Pipelines mit der Zugriffsentscheidung zurück. Phasenbereitstellung kann fortgesetzt werden
Wenn Sie die empfohlene Implementierung verwenden, zeigt die Seite „Details zur Pipelineausführung“ das neueste Prüfprotokoll an.
Empfohlene Konfiguration für asynchrone Überprüfungen
Vergewissern Sie sich im Konfigurationsbereich der Azure-Funktions-/REST-API-Überprüfung, dass Sie wie folgt vorgegangen sind:
- Rückruf für das Abschlussereignis ausgewählt
- Zeit zwischen Auswertungen (Minuten) auf 0 festgelegt
Das Festlegen von Zeit zwischen Auswertungen auf einen Wert ungleich Null bedeutet, dass die Entscheidung der Überprüfung (bestanden/nicht bestanden) nicht endgültig ist. Die Überprüfung wird neu ausgewertet, bis alle anderen Genehmigungen und Überprüfungen einen endgültigen Zustand erreicht haben.
Informationen zur Pipelineausführung an Überprüfungen übergeben
Bei der Konfiguration der Überprüfung können Sie die Informationen zur Pipelineausführung angeben, die Sie an Ihre Überprüfung senden möchten. Zumindest sollten Sie Folgendes senden:
"PlanUrl": "$(system.CollectionUri)"
"ProjectId": "$(system.TeamProjectId)"
"HubName": "$(system.HostType)"
"PlanId": "$(system.PlanId)"
"JobId": "$(system.JobId)"
"TaskInstanceId": "$(system.TaskInstanceId)"
"AuthToken": "$(system.AccessToken)"
Diese Schlüssel-Wert-Paare werden standardmäßig in den Headers
des REST-Aufrufs von Azure Pipelines festgelegt.
Sie sollten AuthToken
verwenden, um Azure DevOps aufzurufen, z. B. wenn Ihre Überprüfung mit einer Entscheidung zurückruft.
Aufruf in Azure DevOps
Um eine Entscheidung zu treffen, benötigt Ihre Überprüfung möglicherweise Informationen über die aktuelle Pipelineausführung, die nicht an die Überprüfung weitergegeben werden können, sodass die Überprüfung sie abrufen muss. Stellen Sie sich vor, Ihre Überprüfung verifiziert, dass eine Pipelineausführung eine bestimmte Aufgabe ausgeführt hat, z. B. eine statische Analyseaufgabe. Ihre Überprüfung muss Azure DevOps aufrufen und die Liste der bereits ausgeführten Aufgaben abrufen.
Für einen Aufruf in Azure DevOps wird empfohlen, anstelle eines persönlichen Zugriffstokens (PAT) das Auftragszugriffstoken zu verwenden, das für die Ausführung der Überprüfung ausgestellt wurde. Das Token wird Ihren Überprüfungen bereits standardmäßig im AuthToken
-Header zur Verfügung gestellt.
Im Vergleich zu PATs ist das Auftragszugriffstoken weniger anfällig für eine Drosselung, muss nicht manuell aktualisiert werden und ist nicht an ein persönliches Konto gebunden. Das Token ist 48 Stunden lang gültig.
Mithilfe des Auftragszugriffstokens können Sie die Probleme mit der Drosselung der Azure DevOps-REST-API fast vollständig entfernen. Wenn Sie ein PAT verwenden, verwenden Sie dasselbe PAT für alle Ausführungen Ihrer Pipeline. Wenn Sie eine große Anzahl von Pipelines ausführen, wird das PAT gedrosselt. Beim Auftragszugriffstoken ist dies weniger problematisch, da für jede Überprüfungsausführung ein neues Token generiert wird.
Das Token wird für die Buildidentität ausgestellt, die zum Ausführen einer Pipeline verwendet wird, z. B. FabrikamFiberChat-Builddienst (FabrikamFiber). Das Token kann also verwendet werden, um auf dieselben Repositorys oder Pipelineausführungen zuzugreifen, die von der Hostpipeline ausgeführt werden können. Wenn Sie Zugriff auf Repositorys in YAML-Pipelines schützen aktiviert haben, wird der Gültigkeitsbereich weiter auf die Repositorys eingeschränkt, auf die in der Pipelineausführung verwiesen wird.
Wenn Ihre Überprüfung auf Ressourcen zugreifen muss, die nicht mit den Pipelines zusammenhängen, z. B. Boards User Stories, sollten Sie diese Berechtigungen den Buildidentitäten der Pipelines erteilen. Wenn Ihre Überprüfung von mehreren Projekten aus ausgelöst werden kann, stellen Sie sicher, dass alle Pipelines in allen Projekten auf die erforderlichen Ressourcen zugreifen können.
Zurücksenden einer Entscheidung an Azure DevOps
Die Implementierung Ihrer Überprüfung muss den Post Event-REST-API-Aufruf verwenden, um eine Entscheidung an Azure Pipelines zurückzusenden. Stellen Sie sicher, dass Sie die folgenden Eigenschaften angeben:
Headers
:Bearer {AuthToken}
Body
:
{
"name": "TaskCompleted",
"taskId": "{TaskInstanceId}",
"jobId": "{JobId}",
"result": "succeeded|failed"
}
Senden von Statusaktualisierungen an Azure DevOps von Überprüfungen
Sie können Azure Pipelines-Benutzern Statusaktualisierungen aus Ihren Überprüfungen heraus zur Verfügung stellen, indem Sie Azure Pipelines-REST-APIs verwenden. Diese Funktion ist z. B. nützlich, wenn Sie Benutzer wissen lassen möchten, dass die Überprüfungen auf eine externe Aktion wartet, z. B. wenn ein ServiceNow-Ticket genehmigt werden muss.
Die Schritte zum Senden von Statusaktualisierungen sind:
- Erstellen eines Aufgabenprotokolls
- Anfügen an das Aufgabenprotokoll
- Aktualisieren des Datensatzes der Zeitleiste
Alle REST-API-Aufrufe müssen authentifiziert werden.
Beispiele
Grundlegende Azure-Funktionsüberprüfung
In diesem grundlegenden Beispiel überprüft die Azure-Funktion, ob die aufrufende Pipeline eine CmdLine
-Aufgabe ausgeführt hat, bevor sie ihr Zugriff auf eine geschützte Ressource gewährt.
Die Azure-Funktion durchläuft die folgenden Schritte:
- Bestätigen des Empfangs der Nutzdaten der Überprüfung
- Senden einer Statusaktualisierung an Azure Pipelines, dass die Überprüfung gestartet wurde
- Verwenden eines
{AuthToken}
, um einen Rückruf in Azure Pipelines zu tätigen, um den Timeline-Eintrag der Pipelineausführung abzurufen - Überprüfen, ob die Zeitachse eine Aufgabe mit
"id": "D9BAFED4-0B18-4F58-968D-86655B4D2CE9"
(der ID der AufgabeCmdLine
) enthält - Senden einer Statusaktualisierung mit dem Ergebnis der Suche
- Senden einer Entscheidung zur Überprüfung an Azure Pipelines
Sie können dieses Beispiel aus GitHub herunterladen.
Um diese Azure-Funktionsüberprüfung zu verwenden, müssen Sie bei der Konfiguration der Überprüfung den folgenden Headers
angeben:
{
"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)"
}
Erweiterte Azure-Funktionsüberprüfung
In diesem erweiterten Beispiel prüft die Azure-Funktion, ob sich das Azure Boards-Arbeitselement, auf das in der Commitnachricht verwiesen wird, die die Pipelineausführung ausgelöst hat, im richtigen Zustand befindet.
Die Azure-Funktion durchläuft die folgenden Schritte:
- Bestätigen des Empfangs der Nutzdaten der Überprüfung
- Senden einer Statusaktualisierung an Azure Pipelines, dass die Überprüfung gestartet wurde
- Verwenden von
{AuthToken}
für einen Rückruf in Azure Pipelines, um den Zustand des Azure Boards-Arbeitselements abzurufen, auf das in der Commitnachricht verwiesen wird, die die Pipelineausführung ausgelöst hat - Überprüfen, ob sich das Arbeitselement im Zustand
Completed
befindet - Senden einer Statusaktualisierung mit dem Ergebnis der Überprüfung
- Wenn sich das Arbeitselement nicht im Zustand
Completed
befindet, wird eine weitere Auswertung in einer Minute eingeplant. - Sobald sich das Arbeitselement im richtigen Zustand befindet, sendet es eine positive Entscheidung an Azure Pipelines
Sie können dieses Beispiel aus GitHub herunterladen.
Um diese Azure-Funktionsüberprüfung zu verwenden, müssen Sie bei der Konfiguration der Überprüfung den folgenden Headers
angeben:
{
"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)"
}
Fehlerbehandlung
Derzeit wertet Azure Pipelines eine einzelne Überprüfungsinstanz höchstens 2.000 Mal aus.
Wenn Ihre Überprüfung nicht innerhalb der konfigurierten Zeitspanne in Azure Pipelines zurückruft, wird die zugeordnete Phase übersprungen. Davon abhängige Phasen werden ebenfalls übersprungen.
Synchrone Überprüfungen
Im synchronen Modus ruft Azure DevOps die Azure-Funktions-/REST-API-Überprüfung auf, um eine sofortige Entscheidung zu erhalten, ob der Zugriff auf eine geschützte Ressource erlaubt ist.
Die Implementierung des synchronen Modus für eine einzelne Azure-Funktionsüberprüfung ist im folgenden Diagramm dargestellt.
Führen Sie die folgenden Schritte durch:
- Azure Pipelines bereitet die Bereitstellung einer Pipelinephase vor und benötigt Zugriff auf eine geschützte Ressource.
- Es wechselt in eine innere Schleife, in der Folgendes geschieht:
- 2.1. Azure Pipelines ruft die entsprechende Azure-Funktionsüberprüfung auf und wartet auf eine Entscheidung.
- 2.2. Ihre Azure-Funktion wertet die Bedingungen aus, die erforderlich sind, um den Zugriff zu ermöglichen, und gibt eine Entscheidung zurück.
- 2.3. Wenn der Antworttext der Azure-Funktion die von Ihnen definierten Erfolgskriterien nicht erfüllt und die Option Zeit zwischen Auswertungen ungleich Null ist, plant Azure Pipelines eine weitere Überprüfungsauswertung nach Zeit zwischen Auswertungen.
Konfigurieren synchroner Überprüfungen
Um den synchronen Modus für die Azure-Funktion/REST-API zu verwenden, stellen Sie im Bereich zum Überprüfen der Konfiguration Folgendes sicher:
- ApiResponse ist für das Completion-Ereignis unter Erweitert ausgewählt.
- Erfolgskriterien, die definieren, wann die Überprüfung auf der Grundlage des Antworttexts der Überprüfung bestanden wird, sind angegeben.
- Zeit zwischen Auswertungen ist unter Kontrolloptionen auf 0 festgelegt.
- Für Timeout ist festgelegt, wie lange Sie auf den Erfolg einer Überprüfung warten möchten. Wenn es keine positive Entscheidung gibt und Timeout erreicht ist, wird die entsprechende Pipelinephase übersprungen.
Die Einstellung Zeit zwischen Auswertungen legt fest, wie lange die Entscheidung der Überprüfung gültig ist. Ein Wert von 0 bedeutet, dass die Entscheidung endgültig ist. Ein Wert ungleich Null bedeutet, dass die Überprüfung nach dem konfigurierten Intervall erneut versucht wird, wenn die Entscheidung negativ ausfällt. Wenn mehrere Genehmigungen und Überprüfungen ausgeführt werden, wird die Überprüfung unabhängig von der Entscheidung erneut versucht.
Die maximale Anzahl der Auswertungen wird durch das Verhältnis zwischen den Werten Timeout und Zeit zwischen Auswertungen definiert. Wir empfehlen Ihnen, darauf zu achten, dass dieses Verhältnis höchstens 10 beträgt.
Informationen zur Pipelineausführung an Überprüfungen übergeben
Beim Konfigurieren der Überprüfung können Sie die Informationen zur Pipelineausführung angeben, die Sie an Ihre Azure-Funktions-/REST-API-Überprüfung senden möchten. Standardmäßig fügt Azure Pipeline die folgenden Informationen in die Headers
des HTTP-Aufrufs ein, der getätigt wird.
"PlanUrl": "$(system.CollectionUri)"
"ProjectId": "$(system.TeamProjectId)"
"HubName": "$(system.HostType)"
"PlanId": "$(system.PlanId)"
"JobId": "$(system.JobId)"
"TaskInstanceId": "$(system.TaskInstanceId)"
"AuthToken": "$(system.AccessToken)"
Wir raten davon ab, Azure DevOps im synchronen Modus aufzurufen, da dies höchstwahrscheinlich dazu führt, dass Ihre Überprüfung mehr als drei Sekunden für die Antwort benötigt, sodass die Überprüfung fehlschlägt.
Fehlerbehandlung
Derzeit wertet Azure Pipelines eine einzelne Überprüfungsinstanz höchstens 2.000 Mal aus.
Zeitpunkt für die Verwendung der asynchronen und synchronen Überprüfungen
Schauen wir uns einige Beispielanwendungsfälle und die empfohlenen Überprüfungen an.
Externe Informationen müssen korrekt sein.
Angenommen, Sie verfügen über eine Dienstverbindung mit einer Produktionsressource und möchten sicherstellen, dass der Zugriff auf diese Ressource nur dann erlaubt ist, wenn die Informationen in einem ServiceNow-Ticket korrekt sind. In diesem Fall würde der Ablauf folgendermaßen aussehen:
- Sie fügen eine asynchrone Azure-Funktionsüberprüfung hinzu, die die Richtigkeit des ServiceNow-Tickets überprüft.
- Wenn eine Pipeline, die die Dienstverbindung verwenden möchte, ausgeführt wird:
- Azure Pipelines ruft Ihre Überprüfungsfunktion auf.
- Wenn die Informationen nicht korrekt sind, gibt die Überprüfung eine negative Entscheidung zurück. Nehmen Sie dieses Ergebnis an.
- Die Pipelinephase ist fehlerhaft.
- Sie aktualisieren die Informationen im ServiceNow-Ticket.
- Sie starten die fehlerhafte Phase neu.
- Die Überprüfung wird erneut ausgeführt und diesmal ist sie erfolgreich.
- Die Pipelineausführung wird fortgesetzt.
Externe Genehmigung muss erteilt werden.
Angenommen, Sie verfügen über eine Dienstverbindung mit einer Produktionsressource und möchten sicherstellen, dass der Zugriff darauf nur nach Genehmigung eines ServiceNow-Tickets durch einen Administrator möglich ist. In diesem Fall würde der Ablauf folgendermaßen aussehen:
- Sie fügen eine asynchrone Azure-Funktionsüberprüfung hinzu, die überprüft, ob das ServiceNow-Ticket genehmigt wurde.
- Wenn eine Pipeline, die die Dienstverbindung verwenden möchte, ausgeführt wird:
- Azure Pipelines ruft Ihre Überprüfungsfunktion auf.
- Wenn das ServiceNow-Ticket nicht genehmigt wird, sendet die Azure-Funktion eine Aktualisierung an Azure Pipelines und plant sich selbst erneut ein, um den Status des Tickets in 15 Minuten zu überprüfen.
- Sobald das Ticket genehmigt ist, ruft die Überprüfung Azure Pipelines mit einer positiven Entscheidung zurück.
- Die Pipelineausführung wird fortgesetzt.
Der Entwicklungsprozess wurde befolgt.
Angenommen, Sie verfügen über eine Dienstverbindung mit einer Produktionsressource und möchten sicherstellen, dass der Zugriff auf diese Ressource nur dann erlaubt ist, wenn die Codeabdeckung über 80 % liegt. In diesem Fall würde der Ablauf folgendermaßen aussehen:
- Sie schreiben Ihre Pipeline so, dass Fehler in den einzelnen Phasen zu Fehlern beim Build führen.
- Sie fügen eine asynchrone Azure-Funktionsüberprüfung hinzu, die die Codeabdeckung für die zugehörige Pipelineausführung überprüft.
- Wenn eine Pipeline, die die Dienstverbindung verwenden möchte, ausgeführt wird:
- Azure Pipelines ruft Ihre Überprüfungsfunktion auf.
- Wenn die Bedingung für die Codeabdeckung nicht erfüllt ist, gibt die Überprüfung eine negative Entscheidung zurück. Nehmen Sie dieses Ergebnis an.
- Der Überprüfungsfehler führt dazu, dass die Phase fehlerhaft ist, wodurch die Pipelineausführung fehlschlägt.
- Das Entwicklungsteam fügt die notwendigen Komponententests hinzu, um eine Codeabdeckung von 80 % zu erreichen.
- Eine neue Pipelineausführung wird ausgelöst, und dieses Mal wird die Überprüfung bestanden
- Die Pipelineausführung wird fortgesetzt.
Die Leistungskriterien müssen erfüllt sein.
Angenommen, Sie stellen neue Versionen Ihres Systems in mehreren Schritten bereit, beginnend mit einer Canary-Bereitstellung. Sie möchten sicherstellen, dass die Leistung Ihrer Canary-Bereitstellung angemessen ist. In diesem Fall würde der Ablauf folgendermaßen aussehen:
- Sie fügen eine asynchrone Azure-Funktionsüberprüfung hinzu.
- Wenn eine Pipeline, die die Dienstverbindung verwenden möchte, ausgeführt wird:
- Azure Pipelines ruft Ihre Überprüfungsfunktion auf.
- Die Überprüfung startet einen Leistungsmonitor für die Canary-Bereitstellung.
- Die Überprüfung plant mehrere Auswertungsprüfpunkte, um zu sehen, wie sich die Leistung entwickelt hat.
- Sobald Sie ausreichend Vertrauen in die Leistung der Canary-Bereitstellung gewonnen haben, führt Ihre Azure-Funktion einen Rückruf in Azure Pipelines mit einer positiven Entscheidung aus.
- Die Pipelineausführung wird fortgesetzt.
Der Grund für die Bereitstellung muss gültig sein.
Angenommen, Sie verfügen über eine Dienstverbindung mit einer Ressource der Produktionsumgebung und möchten sicherstellen, dass der Zugriff darauf nur für manuell in Warteschlangen gestellte Builds erfolgt. In diesem Fall würde der Ablauf folgendermaßen aussehen:
- Sie fügen eine synchrone Azure-Funktionsüberprüfung hinzu, die überprüft, ob
Build.Reason
für die Pipelineausführung entsprechendManual
ist. - Sie konfigurieren die Azure-Funktionsüberprüfung, um
Build.Reason
in ihrenHeaders
zu übergeben. - Sie legen Zeit zwischen Auswertungen der Überprüfung auf 0 fest, sodass Misserfolg oder Erfolg endgültig sind und keine erneute Auswertung erforderlich ist.
- Wenn eine Pipeline, die die Dienstverbindung verwenden möchte, ausgeführt wird:
- Azure Pipelines ruft Ihre Überprüfungsfunktion auf.
- Wenn der Grund ein anderer als
Manual
ist, ist die Überprüfung nicht erfolgreich und die Pipelineausführung schlägt fehl.
Kompatibilität prüfen
Aufrufen von Azure Function- und REST-API-Prüfungen enthalten jetzt Regeln, die der empfohlenen Verwendung entsprechen. Prüfungen müssen je nach Modus und Anzahl der Wiederholungen diese Regeln:
Asynchrone Überprüfungen (Rückrufmodus): Azure-Pipelines wiederholen keine asynchronen Überprüfungen. Sie sollten ein Ergebnis asynchron bereitstellen, wenn eine Auswertung abgeschlossen ist. Damit asynchrone Prüfungen als konform betrachtet werden, muss das Zeitintervall zwischen Auswertungen 0 sein.
Synchrone Überprüfungen (ApiResponse-Modus): Die maximale Anzahl von Wiederholungen für Ihre Prüfung beträgt 10. Sie können diese auf verschiedene Arten festlegen. Sie können z. B. den Timeout auf 20 und das Zeitintervall zwischen Auswertungen auf 2 konfigurieren. Oder Sie können den Timeout auf 100 und das Zeitintervall zwischen Auswertungen auf 10 konfigurieren. Wenn Sie den Timeout jedoch auf 100 konfigurieren und das Zeitintervall zwischen Auswertungen auf 2 festlegen, ist Ihre Prüfung nicht konform, da Sie hier um 50 Wiederholungsversuche bitten. Das Verhältnis von Timeout zu Zeitintervall zwischen Auswertungen sollte kleiner oder gleich 10 sein.
Erfahren Sie mehr über das Rollout der Überprüfungscompliance.
Mehrere Überprüfungen
Bevor Azure Pipelines eine Phase in einer Pipelineausführung bereitstellt, müssen unter Umständen mehrere Überprüfungen erfolgreich durchgeführt werden. Einer geschützten Ressource können eine oder mehrere Überprüfungen zugeordnet sein. In einer Phase können mehrere geschützte Ressourcen verwendet werden. Azure Pipelines sammelt alle Überprüfungen, die jeder in einer Phase verwendeten geschützten Ressource zugeordnet sind, und wertet sie gleichzeitig aus.
Eine Pipelineausführung darf nur in einer Phase bereitgestellt werden, wenn alle Überprüfungen gleichzeitig erfolgreich sind. Eine einzelne endgültige negative Entscheidung führt dazu, dass der Pipeline der Zugriff verweigert wird und die Phase nicht erfolgreich ist.
Wenn Sie Überprüfungen auf die empfohlene Weise (asynchron, mit endgültigen Zuständen) verwenden, sind ihre Zugriffsentscheidungen endgültig und erleichtern das Verständnis für den Zustand des Systems.
Beispiele finden Sie im Abschnitt Mehrere Genehmigungen und Überprüfungen.