Definiera godkännanden och kontroller

Azure DevOps Services

En pipeline består av steg. En pipelineförfattare kan styra om en fas ska köras genom att definiera villkor på fasen. Ett annat sätt att styra om och när en fas ska köras är genom godkännanden och kontroller.

Godkännanden och andra kontroller definieras inte i yaml-filen. Användare som ändrar yaml-pipelinefilen kan inte ändra de kontroller som utförs innan en fas påbörjas. Administratörer av resurser hanterar kontroller med hjälp av webbgränssnittet för Azure Pipelines.

Pipelines förlitar sig på resurser som miljöer, tjänstanslutningar, agentpooler, variabelgrupper och säkra filer. Kontroller gör det möjligt för resursägaren att kontrollera om och när en fas i en pipeline kan förbruka en resurs. Som ägare av en resurs kan du definiera kontroller som måste uppfyllas innan en fas som förbrukar resursen kan starta. En manuell godkännandekontroll i en miljö säkerställer till exempel att distributionen till den miljön endast sker efter att den utsedda användaren har granskat de ändringar som distribueras.

En fas kan bestå av många jobb och varje jobb kan förbruka flera resurser. Innan körningen av en fas kan påbörjas måste alla kontroller av alla resurser som används i den fasen vara uppfyllda. Azure Pipelines pausar körningen av en pipeline före varje steg och väntar tills alla väntande kontroller har slutförts.

Det finns fem kategorier av godkännanden och kontroller och de körs i den ordning de skapades inom varje kategori. Kontrollerna utvärderas på nytt baserat på det återförsöksintervall som anges i varje kontroll. Om alla kontroller inte lyckas förrän tidsgränsen har angetts körs inte den fasen. Om någon av kontrollerna misslyckas terminalt (till exempel om du avvisar ett godkännande för en av resurserna) körs inte den fasen. Du kan dock försöka igen när godkännanden och tidsgränsen överskrids.

Statiska kontroller körs först och sedan körs förhandskontrollgodkännanden. Kategorierna i ordning är:

1. Statiska kontroller: Grenkontroll, Obligatorisk mall och Utvärdera artefakt
2. Förhandskontrollera godkännanden
3. Dynamiska kontroller: Godkännande, Anropa Azure-funktion, Anropa REST API, Kontorstid, Fråga Azure Monitor-aviseringar
4. Godkännanden efter kontroll
5. Exklusivt lås

Du kan också se körningsordningen på fliken Godkännanden och kontroller.

Viktigt!

Kontroller kan konfigureras för miljöer, tjänstanslutningar, lagringsplatser, variabelgrupper, säkra filer och agentpooler.

Tjänstanslutningar kan inte anges med variabel.

Godkännanden

Du kan manuellt styra när en fas ska köras med godkännande och kontroller. Den här kontrollen används ofta för att styra distributioner till produktionsmiljöer.

1. Logga in på din Azure DevOps-organisation och navigera sedan till projektet.

2. Välj Pipelines-miljöer> och välj sedan din miljö.

3. Välj fliken Godkännanden och checkar och välj + sedan tecknet för att lägga till en ny kontroll.

   

4. Välj Godkännanden och välj sedan Nästa.

5. Lägg till användare eller grupper som dina utsedda godkännare och, om så önskas, ange instruktioner för godkännarna. Ange om du vill tillåta eller begränsa godkännare från att godkänna sina egna körningar och ange önskad tidsgräns. Om godkännanden inte har slutförts inom den angivna tidsgränsen markeras fasen som överhoppad.

6. Välj Skapa när du är klar.

   

7. När godkännandekontrollen har utlösts visas ett promptfönster, som du ser i exemplet nedan, i användargränssnittet. Det här fönstret innehåller alternativet för godkännare att antingen avvisa eller godkänna körningen, tillsammans med eventuella tillhörande instruktioner.

   

Listan över användare som kan granska ett godkännande har åtgärdats när godkännanden och kontroller börjar köras. Det innebär att ändringar i listan över användare och grupper av en godkännandekontroll som gjorts när kontrollerna börjar köras inte hämtas.

Kommentar

Om en grupp har utsetts till godkännare behöver endast en användare i gruppen godkänna körningen för att köras.

Uppskjutna godkännanden

Det finns situationer när tiden när ett godkännande ges och den tid då distributionen ska starta inte matchar. Du kanske till exempel vill vänta med att distribuera en ny version tills en låg trafiktid på kvällen.

För att åtgärda det här scenariot kan du skjuta upp ett godkännande och ange den tid då godkännandet träder i kraft.

1. Välj Skjut upp godkännande.

   

2. Ange godkännandetiden.

   

Godkännandet visas i panelen Kontroller som ett förhandsgodkännande. Godkännandet träder i kraft vid den angivna tidpunkten.

Grenkontroll

Med kontrollkontrollen för grenen kan du se till att alla resurser som är länkade med pipelinen skapas från de tillåtna grenarna och att grenarna har skydd aktiverat. Den här kontrollen hjälper dig att kontrollera distributionernas beredskap och kvalitet. Om flera resurser är länkade till pipelinen verifieras källan för alla resurser. Om du har länkat en annan pipeline verifieras grenen av den specifika körning som distribueras för skydd.

Så här definierar du kontrollen för grenkontroll:

1. I ditt Azure DevOps-projekt går du till den resurs (till exempel miljö) som måste skyddas.

2. Gå till Godkännanden och Söker efter resursen.

3. Välj kontrollen Grenkontroll och ange en kommaavgränsad lista över tillåtna grenar. Du kan kräva att grenen ska ha skydd aktiverat. Du kan också definiera beteendet för kontrollen om skyddsstatusen för en av grenarna inte är känd.

   

Vid körningen validerar kontrollen grenar för alla länkade resurser i körningen mot listan över tillåtna. Om någon av grenarna inte matchar kriterierna misslyckas kontrollen och fasen markeras som misslyckad.

Kommentar

Kontrollen kräver att grennamnen är fullständigt kvalificerade. Kontrollera att formatet för grennamnet är refs/heads/<branch name>

Kontorstid

Om du bara vill att alla distributioner till din miljö ska ske under en viss tidsperiod är kontorstidskontroll den perfekta lösningen. När du kör en pipeline väntar körningen av fasen som använder resursen i kontorstid. Om du har flera körningar som körs samtidigt verifieras var och en av dem oberoende. I början av kontorstid markeras kontrollen som lyckad för alla körningar.

Om körningen av fasen inte har startat i slutet av kontorstid (som fördröjs av någon annan kontroll), återkallas godkännandet av kontorstid automatiskt och en omvärdering schemaläggs för nästa dag. Kontrollen misslyckas om körningen av fasen inte startar inom den tidsgräns som angetts för kontrollen och fasen markeras som misslyckad.

Anropa Azure-funktionen

Azure-funktioner är den serverlösa beräkningsplattform som erbjuds av Azure. Med Azure-funktioner kan du köra små delar av koden (kallas "funktioner") utan att behöva bekymra dig om programinfrastrukturen. Med tanke på den höga flexibiliteten är Azure-funktioner ett bra sätt att skapa egna kontroller. Du inkluderar logiken för incheckningsfunktionen i Azure så att varje körning utlöses på http-begäran, har en kort körningstid och returnerar ett svar. När du definierar kontrollen kan du parsa svarstexten för att härleda om kontrollen lyckas. Utvärderingen kan upprepas regelbundet med inställningen Tid mellan utvärderingar i kontrollalternativ. Läs mer

Om kontrollen inte lyckas inom den konfigurerade tidsgränsen hoppas den associerade fasen över. Steg beroende på den hoppas också över. Mer information finns i Azure Function App-uppgiften.

Kommentar

Användardefinierade pipelinevariabler är tillgängliga för kontrollen som börjar med Sprint 215.

Läs mer om det rekommenderade sättet att använda anropa Azure-funktionskontroller. Kontroller måste följa specifika regler beroende på deras läge och antalet återförsök som ska vara kompatibla.

Anropa REST API

Genom att anropa REST API-kontrollen kan du integrera med någon av dina befintliga tjänster. Gör regelbundet ett anrop till ett REST API och fortsätt om det returnerar ett lyckat svar. Läs mer

Utvärderingen kan upprepas regelbundet med inställningen Tid mellan utvärderingar i kontrollalternativ. Om kontrollen inte lyckas inom den konfigurerade tidsgränsen hoppas den associerade fasen över. Steg beroende på den hoppas också över. Mer information finns i Anropa REST API-uppgift.

Kommentar

Användardefinierade pipelinevariabler är tillgängliga för kontrollen som börjar med Sprint 215.

Läs mer om det rekommenderade sättet att använda anropa REST API-kontroller.

Fråga Azure Monitor-aviseringar

Azure Monitor erbjuder visualisering, frågor, routning, aviseringar, autoskalning och automatisering av data från Azure-infrastrukturen och varje enskild Azure-resurs. Aviseringar är ett standardsätt för att identifiera problem med infrastrukturens eller programmets hälsotillstånd och vidta korrigerande åtgärder. Kanariedistributioner och mellanlagrade distributioner är vanliga distributionsstrategier som används för att minska risken för regressioner till kritiska program. När du har distribuerat till en fas (uppsättning kunder) observeras programmet under en tidsperiod. Hälsotillståndet för programmet efter distributionen används för att avgöra om uppdateringen ska göras till nästa steg eller inte.

Fråga Azure Monitor-aviseringar hjälper dig att observera Azure Monitor och se till att inga aviseringar genereras för programmet efter en distribution. Kontrollen lyckas om inga aviseringsregler aktiveras vid tidpunkten för utvärderingen. Läs mer

Utvärderingen upprepas efter tid mellan utvärderingsinställningen i kontrollalternativ. Kontrollerna misslyckas om fasen inte har startat körningen inom den angivna tidsgränsperioden .

Obligatorisk mall

Med den nödvändiga mallkontrollen kan du framtvinga pipelines för att använda en specifik YAML-mall. När den här kontrollen är på plats misslyckas en pipeline om den inte sträcker sig från den refererade mallen.

Så här definierar du ett obligatoriskt mallgodkännande:

1. I ditt Azure DevOps-projekt går du till den tjänstanslutning som du vill begränsa.

2. Öppna Godkännanden och Checkar på menyn bredvid Redigera.

3. I menyn Lägg till din första kontroll väljer du Obligatorisk mall.

4. Ange information om hur du kommer till den mallfil som krävs.

   • Lagringsplatstyp: Platsen för din lagringsplats (GitHub, Azure eller Bitbucket).
   • Lagringsplats: Namnet på din lagringsplats som innehåller mallen.
   • Referens: Grenen eller taggen för den mall som krävs.
   • Sökväg till nödvändig mall: Namnet på mallen.

Du kan ha flera mallar som krävs för samma tjänstanslutning. I det här exemplet är production_template.yamlmallen som krävs .

Inaktivera en kontroll

När du felsöker en kontroll kanske du tillfälligt vill inaktivera och sedan aktivera den igen. Så här inaktiverar eller aktiverar du en kontroll:

1. I ditt Azure DevOps-projekt går du till resursen med en kontroll.

2. Öppna fliken Godkännanden och Kontroller.

3. I snabbmenyn väljer du Inaktivera eller Aktivera.

   

Kringgå en kontroll

I vissa fall, till exempel en snabbkorrigeringsdistribution, kan du behöva kringgå en kontroll. Du kan bara kringgå en kontroll om du har administratörsbehörighet för resursen där kontrollen har definierats.

Om du vill kringgå ett godkännande, kontorstid, anropa Azure-funktionen eller anropa REST API-kontrollen väljer du Kringgå kontroll när resursen väntar på granskning. Här är ett exempel på hur du kringgår kontorstidskontrollen.

När du kringgår en kontroll ser du vem som förbigick kontrollen i kontrollpanelen.

Utvärdera artefakt

Du kan utvärdera artefakter som ska distribueras till en miljö mot anpassade principer.

Kommentar

För närvarande fungerar detta endast med containeravbildningsartefakter

Om du vill definiera en anpassad principutvärdering över artefakterna följer du stegen nedan.

1. I ditt Azure DevOps Services-projekt navigerar du till den miljö som måste skyddas. Läs mer om att skapa en miljö.

   

2. Gå till Godkännanden och sök efter miljön.

   

3. Välj Utvärdera artefakt.

   

4. Klistra in principdefinitionen och välj Spara. Läs mer om att skriva principdefinitioner.

   

När du kör en pipeline pausar körningen av den körningen innan du går in i en fas som använder miljön. Den angivna principen utvärderas mot tillgängliga bildmetadata. Kontrollen godkänns när principen lyckas och annars misslyckas. Fasen har markerats som misslyckad om kontrollen misslyckas.

Passerade

Du kan också se de fullständiga loggarna för principkontrollerna från pipelinevyn.

Misslyckades

Du kan också se de fullständiga loggarna för principkontrollerna från pipelinevyn.

Exklusivt lås

Med den exklusiva låskontrollen kan endast en enda körning från pipelinen fortsätta. Alla steg i alla körningar av pipelinen som använder resursen pausas. När fasen med låset har slutförts kan en annan fas fortsätta att använda resursen. Dessutom tillåts endast en fas att fortsätta.

Beteendet för andra steg som försöker ta ett lås konfigureras av värdet lockBehavior som har konfigurerats i YAML-filen för pipelinen.

• runLatest – Endast den senaste körningen hämtar låset till resursen. runLatest är standardvärdet om nej lockBehavior har angetts.
• sequential – Alla körningar hämtar låset sekventiellt till den skyddade resursen.

Följ dessa steg om du vill använda exklusiv låskontroll med sequential distributioner eller runLatest:

1. Aktivera den exklusiva låskontrollen i miljön (eller en annan skyddad resurs).
2. I YAML-filen för pipelinen anger du en egenskap med namnet lockBehavior. Detta kan anges för hela pipelinen eller för en viss fas:

Ställ in på en scen:

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

Ställ in på pipelinen:

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

Om du inte anger något lockBehavioranvänds standardvärdet runLatest för .

ServiceNow Ändringshantering

Den här kontrollen kräver att ServiceNow Change Management-tillägget installeras från Marketplace

Kontrollen av servicenow-ändringshantering möjliggör integrering av ServiceNow-ändringshanteringsprocessen i pipelines. Genom att lägga till kontrollen kan en ny ändringsbegäran i ServiceNow skapas automatiskt i början av fasen. Pipelinen väntar på att ändringsprocessen ska slutföras innan fasen startas. Mer information finns här.

Flera Godkännanden och kontroller

En fas kan bestå av många jobb och varje jobb kan förbruka flera resurser. Innan körningen av en fas kan påbörjas måste alla kontroller av alla resurser som används i den fasen vara uppfyllda. Azure Pipelines pausar körningen av en pipeline före varje steg och väntar tills alla väntande kontroller har slutförts.

Ett enda slutligt negativt beslut gör att pipelinen nekas åtkomst och att fasen misslyckas. Besluten för alla godkännanden och kontroller förutom att anropa Azure-funktionen/REST API och Exklusivt lås är slutgiltiga. Du kan köra om lyckade anrop av Azure-funktionen/REST API-kontroller.

När du använder anropa Azure-funktionen/REST API-kontroller på det rekommenderade sättet är deras åtkomstbeslut också slutgiltiga.

När du anger Tid mellan utvärderingar för en anropande Azure-funktion/REST API-kontroll som inte är noll, är kontrollens beslut inte slutgiltigt. Det här scenariot är värt att utforska.

Låt oss titta på ett exempel. Anta att YAML-pipelinen har en fas som använder en tjänstanslutning. Den här tjänstanslutningen har två kontroller konfigurerade för den:

1. En asynkron kontroll, med namnet Externt godkännande beviljat, som verifierar att ett externt godkännande ges och konfigureras på det rekommenderade sättet.
2. En synkron kontroll, med namnet Distributionsorsak giltig, som verifierar att distributionsorsaken är giltig och för vilken du anger tid mellan utvärderingar till 7 minuter.

En möjlig körning av kontroller visas i följande diagram.

I den här körningen:

• Båda kontrollerna, beviljat externt godkännande och giltigt distributionsorsak, anropas samtidigt. Distributionsorsaken giltig misslyckas omedelbart, men eftersom externt godkännande har beviljats kommer det att göras ett nytt försök.
• Vid minut 7 görs ett nytt försök med distributionsorsaken och den här gången går den igenom.
• Vid minut 15 anropar externt godkännande beviljat tillbaka till Azure Pipelines med ett lyckat beslut. Nu går båda kontrollerna igenom, så pipelinen kan fortsätta att distribuera fasen.

Låt oss titta på ett annat exempel som omfattar två synkrona kontroller. Anta att YAML-pipelinen har en fas som använder en tjänstanslutning. Den här tjänstanslutningen har två kontroller konfigurerade för den:

1. En synkron kontroll med namnet Synkroniseringskontroll 1, för vilken du anger tid mellan utvärderingar till 5 minuter.
2. En synkron kontroll med namnet Synkroniseringskontroll 2, för vilken du anger tid mellan utvärderingar till 7 minuter.

En möjlig körning av kontroller visas i följande diagram.

I den här körningen:

• Båda kontrollerna Sync Check 1 och Sync Check 2 anropas samtidigt. Synkroniseringskontroll 1 godkänns, men den kommer att göras om eftersom synkroniseringskontroll 2 misslyckas.
• Vid minut 5 görs synkroniseringskontroll 1 på nytt, men misslyckas, så det görs ett nytt försök.
• Vid minut 7 görs synkroniseringskontroll 2 på nytt och lyckas. Passeringsbeslutet är giltigt i 7 minuter. Om synkroniseringskontroll 1 inte överskrider det här tidsintervallet görs ett nytt försök med synkroniseringskontroll 2 .
• Vid minut 10 görs synkroniseringskontroll 1 på nytt, men misslyckas, så det görs ett nytt försök.
• Vid minut 14 görs synkroniseringskontroll 2 på nytt och lyckas. Passeringsbeslutet är giltigt i 7 minuter. Om synkroniseringskontroll 1 inte överskrider det här tidsintervallet görs ett nytt försök med synkroniseringskontroll 2 .
• Vid minut 15 görs synkroniseringskontroll 1 på nytt och lyckas. Nu går båda kontrollerna igenom, så pipelinen kan fortsätta att distribuera fasen.

Låt oss titta på ett exempel som omfattar ett godkännande och en synkron kontroll. Anta att du har konfigurerat en synkron kontroll och ett godkännande för en tjänstanslutning med en tid mellan utvärderingar på 5 minuter. Tills godkännandet har getts körs din kontroll var 5:e minut, oavsett beslut.

Vanliga frågor

De definierade kontrollerna startade inte. Vad hände?

Utvärderingen av kontrollerna startar när fasvillkoren är uppfyllda. Du bör bekräfta körningen av fasen som startades efter att kontrollerna har lagts till på resursen och att resursen förbrukas i fasen.

Hur kan jag använda kontroller för att schemalägga en fas?

Med hjälp av kontorstidskontrollen kan du styra tiden för start av faskörningen. Du kan uppnå samma beteende som fördefinierade scheman på en fas i designerversioner.

Hur kan jag ta förhandsgodkännanden för en fas som är schemalagd att köras i framtiden?

Det här scenariot kan aktiveras.

1. Med kontrollen kontorstid kan alla faser som distribueras till en resurs schemaläggas för körning mellan tidsfönstret
2. När godkännanden har konfigurerats för samma resurs väntar fasen på godkännanden innan de startas.
3. Du kan konfigurera båda kontrollerna på en resurs. Fasen skulle vänta på godkännanden och kontorstid. Den skulle starta i nästa schemalagda fönster när godkännandena har slutförts.

Kan jag vänta tills säkerhetsgenomsökningen av artefakten har slutförts?

För att vänta tills säkerhetsgenomsökningen av artefakten har slutförts måste du använda en extern genomsökningstjänst som AquaScan. Artefakten som distribueras måste laddas upp på en plats som är tillgänglig för genomsökningstjänsten innan kontrollerna påbörjas och kan identifieras med hjälp av fördefinierade variabler. Med hjälp av kontrollen Anropa REST API kan du lägga till en kontroll för att vänta på API:et i säkerhetstjänsten och skicka artefaktidentifieraren som indata.

Hur kan jag använda utdatavariabler från föregående steg i en kontroll?

Som standard är endast fördefinierade variabler tillgängliga för kontroller. Du kan använda en länkad variabelgrupp för att komma åt andra variabler. Utdatavariabeln från föregående steg kan skrivas till variabelgruppen och nås i kontrollen.

Läs mer

• Anropa Azure Function/REST API-kontroller
• Godkännanden och kontrollerar REST API
• Godkännanden QUERY REST API