Begränsa tillståndsövergångar för arbetsobjekt

Efter flera sprintar i förhandsversionen presenterar vi nu den allmänna versionen av regler för begränsning av tillståndsövergång till alla kunder som en del av Sprint 172-uppdateringen.

Mer information finns i listan Funktioner nedan.

Funktioner

Azure-tavlor

• Regler för begränsning av tillståndsövergång
• Kopiera arbetsobjekt för att kopiera underordnade objekt
• Förbättrade regler för aktiverade och lösta fält
• Systemarbetsobjekttyper på kvarvarande uppgifter och tavlor (privat förhandsversion)

Azure-pipelines

• Exklusiv princip för distributionslås
• Stegvisa filter för pipelineresursutlösare
• Generiska webhookbaserade utlösare för YAML-pipelines
• Stöd och spårning av YAML-resursutlösare
• Banderoll för livewebbplatsincidenter som påverkar pipelines

Azure Artifacts

• Möjlighet att skapa feeds med organisationsomfattning från användargränssnittet

Azure-tavlor

Regler för begränsning av tillståndsövergång

Efter flera sprintar av privat förhandsversion är regler för begränsning av tillståndsövergång nu allmänt tillgängliga för alla kunder. Med den här nya arbetsobjektstypregeln kan du begränsa att arbetsobjekt flyttas från ett tillstånd till ett annat. Du kan till exempel begränsa buggar från Att gå från Nytt till Löst. I stället måste de gå från New –> Active –> Resolved

Du kan också skapa en regel för att begränsa tillståndsövergångar efter gruppmedlemskap. Till exempel kan endast användare i gruppen Godkännare flytta användarberättelser från Ny –> Godkänd.

Kopiera arbetsobjekt för att kopiera underordnade objekt

En av de mest efterfrågade funktionerna för Azure Boards är möjligheten att kopiera ett arbetsobjekt som också kopierar de underordnade arbetsobjekten. I den här sprinten har vi lagt till ett nytt alternativ för att inkludera underordnade arbetsobjekt i dialogrutan kopiera arbetsobjekt. När du väljer det här alternativet kopieras arbetsobjektet och alla underordnade arbetsobjekt (upp till 100).

Förbättrade regler för aktiverade och lösta fält

Hittills har reglerna för Aktiverad av, Aktiverat datum, Löst av och Löst datum varit ett mysterium. De anges endast för systemarbetsobjekttyper och är specifika för tillståndsvärdet "Aktiv" och "Löst". I sprint 172 ändrade vi logiken så att dessa regler inte längre är för ett visst tillstånd. I stället utlöses de av den kategori (tillståndskategori) som tillståndet finns i. Anta till exempel att du har ett anpassat tillstånd för "Behovstestning" i kategorin Löst. När arbetsobjektet ändras från "Aktiv" till "Behöver testas" utlöses reglerna Löst efter och Löst datum .

Detta gör att kunderna kan skapa anpassade tillståndsvärden och fortfarande generera fälten Aktiverad av, Aktiverat datum, Löst efter och Löst datum , utan att behöva använda anpassade regler.

Systemarbetsobjekttyper på kvarvarande uppgifter och tavlor (privat förhandsversion)

Sedan arvsprocessmodellen startades har flera typer av arbetsobjekt uteslutits från att läggas till i tavlor och kvarvarande uppgifter. Dessa typer av arbetsobjekt är:

Process	Typ av arbetsobjekt
Flexibel	Problem
Scrum	Hinder
CMMI	Ändringsbegäran
	Problem
	Granskning
	Risk

Från och med den här sprinten tillåter vi en privat förhandsversion för de kunder som vill att dessa typer av arbetsobjekt ska vara tillgängliga på alla kvarvarande nivåer.

Om du är intresserad av att förhandsgranska den här funktionen kan du skicka ett e-postmeddelande till oss med ditt organisationsnamn så kan vi ge dig åtkomst.

Azure-pipelines

Exklusiv princip för distributionslås

Med den här uppdateringen kan du se till att endast en enda körning distribueras till en miljö i taget. Genom att välja kontrollen "Exklusivt lås" i en miljö fortsätter bara en körning. Efterföljande körningar som vill distribuera till den miljön pausas. När körningen med det exklusiva låset har slutförts fortsätter den senaste körningen. Alla mellanliggande körningar avbryts.

Stegvisa filter för pipelineresursutlösare

I den här sprinten har vi lagt till stöd för "faser" som ett filter för pipelineresurser i YAML. Med det här filtret behöver du inte vänta tills hela CI-pipelinen har slutförts för att utlösa CD-pipelinen. Nu kan du välja att utlösa cd-pipelinen när en specifik fas i CI-pipelinen har slutförts.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

När stegen i utlösarfiltret har slutförts i DIN CI-pipeline utlöses automatiskt en ny körning för cd-pipelinen.

Generiska webhookbaserade utlösare för YAML-pipelines

Idag har vi olika resurser (till exempel pipelines, containrar, bygge och paket) genom vilka du kan använda artefakter och aktivera automatiserade utlösare. Hittills har du dock inte kunnat automatisera distributionsprocessen baserat på andra externa händelser eller tjänster. I den här versionen introducerar vi stöd för webhook-utlösare i YAML-pipelines för att möjliggöra integrering av pipelineautomatisering med alla externa tjänster. Du kan prenumerera på externa händelser via dess webhooks (GitHub, GitHub Enterprise, Nexus, Artifactory osv.) och utlösa dina pipelines.

Här följer stegen för att konfigurera webhooksutlösare:

1. Konfigurera en webhook på den externa tjänsten. När du skapar webhooken måste du ange följande information:

   • Url för begäran – "https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
   • Hemlighet – det här är valfritt. Om du behöver skydda din JSON-nyttolast anger du värdet Hemlighet

2. Skapa en ny tjänstanslutning för inkommande webhook. Det här är en nyligen introducerad tjänstanslutningstyp som gör att du kan definiera tre viktiga uppgifter:

   • Webhook-namn: Namnet på webhooken ska matcha webhooken som skapats i den externa tjänsten.
   • HTTP-huvud – namnet på HTTP-huvudet i begäran som innehåller nyttolastshashvärdet för verifiering av begäran. När det till exempel gäller GitHub blir begärandehuvudet "X-Hub-Signature"
   • Hemlighet – Hemligheten används för att parsa nyttolastshashen som används för verifiering av den inkommande begäran (detta är valfritt). Om du har använt en hemlighet för att skapa din webhook måste du ange samma hemliga nyckel

   

3. En ny resurstyp med namnet webhooks introduceras i YAML-pipelines. För att prenumerera på en webhook-händelse måste du definiera en webhook-resurs i pipelinen och peka den på den inkommande webhook-tjänstanslutningen. Du kan också definiera ytterligare filter på webhooksresursen baserat på JSON-nyttolastdata för att ytterligare anpassa utlösarna för varje pipeline, och du kan använda nyttolastdata i form av variabler i dina jobb.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

4. När en webhook-händelse tas emot av den inkommande Webhook-tjänstanslutningen utlöses en ny körning för alla pipelines som prenumererar på webhook-händelsen.

Stöd och spårning av YAML-resursutlösare

Det kan vara förvirrande när pipelineutlösare inte kan köras som du förväntar dig. För att bättre förstå detta har vi lagt till ett nytt menyalternativ på pipelinedefinitionssidan med namnet "Utlösarproblem" där information visas om varför utlösare inte körs.

Resursutlösare kan inte köras av två orsaker.

1. Om källan för den angivna tjänstanslutningen är ogiltig, eller om det finns syntaxfel i utlösaren, konfigureras inte utlösaren alls. Dessa visas som fel.

2. Om utlösarvillkoren inte matchas körs inte utlösaren. När detta inträffar visas en varning så att du kan förstå varför villkoren inte matchades.

   

Banderoll för livewebbplatsincidenter som påverkar pipelines

Vi har lagt till en varningsbanderoll på pipelinesidan för att varna användare om pågående incidenter i din region, vilket kan påverka dina pipelines.

Azure Artifacts

Möjlighet att skapa feeds med organisationsomfattning från användargränssnittet

Vi tar tillbaka möjligheten för kunder att skapa och hantera feeds med organisationsomfattning via webbgränssnittet för både lokala och värdbaserade tjänster.

Nu kan du skapa feeds med organisationsomfattning via användargränssnittet genom att gå till Artefakter –> Skapa feed och välja en typ av feed i omfånget.

Vi rekommenderar att du använder feeds med projektomfattning i enlighet med resten av Azure DevOps-erbjudanden, men du kan återigen skapa, hantera och använda feeds med organisationsomfattning via användargränssnittet och olika REST-API:er. Mer information finns i dokumentationen för feeds.

Nästa steg

Kommentar

Dessa funktioner kommer att distribueras under de kommande två till tre veckorna.

Gå över till Azure DevOps och ta en titt.

Gå till Azure DevOps

Så här ger du feedback

Vi vill gärna höra vad du tycker om de här funktionerna. Använd hjälpmenyn för att rapportera ett problem eller ge ett förslag.

Du kan också få råd och dina frågor som besvaras av communityn på Stack Overflow.

Tack,

Aaron Hallberg