Nya förbättringar av leveransplaner 2.0

I den här sprinten förbättrar vi leveransplan 2.0 med nya komprimerade vyer och samlad information. Vi introducerar även manuell validering och en ny uses instruktion för förklaring av resurser i YAML-pipelines .

Mer information finns i listan Funktioner nedan.

Azure-tavlor

• Leveransplaner: Samlad information
• Leveransplaner: Komprimerade vyer

Azure-pipelines

• "uses"-instruktion för förklaring av resurser
• Manuell validering för YAML-pipelines

Azure-tavlor

Leveransplaner: Samlad information

Som en del av den offentliga förhandsversionen av Leveransplaner 2.0 är samlad information nu tillgänglig. När du hanterar arbetsobjekt på högre nivå som epos eller funktioner kanske du vill se mer information. Sammanslagning visar förloppet för de underliggande underordnade arbetsobjekten, vilket avslöjar hela historien. Om du vill aktivera den här funktionen går du till dina planinställningar och sedan Fält och väljer Visa underordnade sammanslagningsdata.

Leveransplaner: Komprimerade vyer

Som en del av den offentliga förhandsversionen av Leveransplaner 2.0 kan kunderna nu växla mellan normal- och kondenserade vyer. Kort med ytterligare fält kan ta upp mycket lodrätt utrymme. Detta gör det svårt att se fler än några kort på skärmen i taget, även när det är helt utzoomat. Vi har skapat en komprimerad kortvy som döljer alla fält från korten och endast visar arbetsobjektets typikon och rubrik. Att dölja och visa alla fält är nu bara ett klick bort.

Azure-pipelines

"uses"-instruktion för förklaring av resurser

När en pipeline kör ett jobb på en agent får agenten en åtkomsttoken för att anropa rest-API:er för Azure Pipelines och ladda ned resurser som lagringsplatser. För YAML-pipelines har vi nyligen lagt till en inställning för att begränsa token till endast de lagringsplatser som faktiskt förbrukas i ett jobb. Vissa kunder använde dock lagringsplatser utan att uttryckligen använda ett checkout steg, till exempel om de använde ett skriptsteg för att anropa Git direkt. Dessa kunder kunde inte aktivera funktionen för tokenbegränsande eftersom Azure Pipelines inte kunde fastställa vilka lagringsplatser som behövdes för jobbet korrekt.

Med den här uppdateringen har vi lagt till ett alternativt sätt att berätta för Azure Pipelines att ett jobb vill använda en lagringsplats utan att använda checkout steget. I stället kan du använda det nya uses nyckelordet, så här:

resources:
  repositories:
  - repository: myrepo
    type: git
    name: MyProject/MyRepo

jobs:
- job: myjob
  uses:
    repositories:
    - myrepo
  steps:
  # without the preceding "uses" statement, if you have the
  # new limit-repositories feature turned on, then Azure Pipelines
  # won't include this repo in the access token and you'll
  # get an access error at runtime (also, in a real pipeline
  # you must include the auth token header as an argument to Git)
  - script: git clone https://dev.azure.com/MyOrg/MyProject/_git/MyRepo

Den här funktionen löser också ett relaterat (men mindre vanligt) problem. Om du använder nyckelordet matrix för att generera flera jobb och dessa jobb använder pooler som anges i matrissteget kan det ha uppstått problem med att auktorisera dessa pooler för pipelinen. Rotorsaken är densamma: eftersom matriser beräknas vid körning kan det överordnade resursauktoriseringssystemet inte exakt avgöra vilka pooler som används. Med kan usesdu deklarera vilka pooler dina jobb ska använda så att de kan auktoriseras i förväg.

jobs:
- job: mtrx
  strategy:
    matrix:
      windows:
        mypoolname: Private-Windows
      mac:
        mypoolname: Private-Mac
  pool: $(mypoolname)
  # without the following "uses" statement, "pool" won't see
  # the pool names until it's too late, and you'll get an error
  # at runtime
  uses:
    pools:
    - Private-Windows
    - Private-Mac

Manuell validering för YAML-pipelines

Med den nyligen utgivna manuella verifieringsuppgiften kan du pausa en YAML-pipeline mitt i fasen. På så sätt kan du utföra manuella eller offlineaktiviteter och sedan återuppta (eller avvisa) körningen. Detta är särskilt användbart i scenarier där du vill pausa en pipeline och låta en peer verifiera konfigurationsinställningar, byggpaket osv. innan du går vidare till ett tidskrävande, beräkningsintensivt jobb. Läs mer.

Nästa steg

Anteckning

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

Gå 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,

Matt Cooper