Skapa en instrumentpanel utan team – Sprint 162 Update

I Sprint 162-uppdateringen av Azure DevOps är vi glada över att kunna meddela att du kan skapa en instrumentpanel utan att koppla den till ett team. Instrumentpanelen visas för alla i projektet och du kan bestämma vem som kan redigera/hantera den.

Dessutom har vi lagt till miniatyrbilden för sprintbrännskada. Nu kan du konfigurera den till burndown baserat på berättelser, artikelpunkter eller antal uppgifter.

Mer information finns i listan Funktioner nedan.

Funktioner

Azure-lagringsplatser:

• Nya landningssidor för konvertering av webbplattform
• Stöd för Kotlin-språk

Azure Pipelines:

• Användargränssnittet för pipelines i flera steg har uppdaterats
• VSTest TestResultsDirectory-alternativet är tillgängligt i aktivitetsgränssnittet
• Använda utökar nyckelord i pipelines
• Stöd för Markdown i automatiska testfelmeddelanden
• Samla in automatiska och användardefinierade metadata från pipelinen
• användargränssnittet för Uppdateringar till tjänstanslutningar
• VM-distributioner med miljöer
• Hoppa över faser i en YAML-pipeline

Rapportering:

• Miniatyrbild av inline sprint burndown
• Skapa en instrumentpanel utan team

Azure-lagringsplatser

Nya landningssidor för konvertering av webbplattform

Vi har uppdaterat användarupplevelsen för lagringsplatsers landningssidor så att den blir modern, snabb och mobilvänlig. Här är två exempel på de sidor som har uppdaterats. Vi fortsätter att uppdatera andra sidor i framtida uppdateringar.

Webbupplevelse:

Mobil upplevelse:

Stöd för Kotlin-språk

Vi är glada att kunna meddela att vi nu stöder Kotlin-språkmarkering i filredigeraren. Markeringen förbättrar läsbarheten för din Kotlin-textfil och hjälper dig att snabbt söka efter fel. Vi prioriterade den här funktionen baserat på ett förslag från utvecklarcommunityn.

Azure-pipelines

Användargränssnittet för pipelines i flera steg har uppdaterats

En uppdaterad version av användargränssnittet för pipelines i flera steg är nu tillgänglig som standard. Upplevelsen av pipelines i flera steg ger förbättringar och enkel användning i pipelinens portalgränssnitt. Du kan visa och hantera dina pipelines genom att välja Pipelines på den vänstra menyn. Dessutom kan du öka detaljnivån och visa pipelineinformation, körningsinformation, pipelineanalys, jobbinformation, loggar med mera.

Mer information om användarupplevelsen för pipelines i flera steg finns i dokumentationen här.

VSTest TestResultsDirectory-alternativet är tillgängligt i aktivitetsgränssnittet

VSTest-aktiviteten lagrar testresultat och associerade filer i $(Agent.TempDirectory)\TestResults mappen. Vi har lagt till ett alternativ i aktivitetsgränssnittet så att du kan konfigurera en annan mapp för att lagra testresultat. Nu kan alla efterföljande uppgifter som behöver filerna på en viss plats använda dem.

Använda utökar nyckelord i pipelines

För närvarande kan pipelines räknas ut i mallar, vilket främjar återanvändning och minskar pannplåten. Den övergripande strukturen för pipelinen definierades fortfarande av YAML-rotfilen. Med den här uppdateringen har vi lagt till ett mer strukturerat sätt att använda pipelinemallar. En YAML-rotfil kan nu använda nyckelordet utökas för att indikera att huvud-pipelinestrukturen finns i en annan fil. Detta ger dig kontroll över vilka segment som kan utökas eller ändras och vilka segment som är fasta. Vi har också förbättrat pipelineparametrar med datatyper för att tydliggöra de krokar som du kan tillhandahålla.

Det här exemplet illustrerar hur du kan tillhandahålla enkla krokar som pipelineförfattaren kan använda. Mallen kör alltid en version, kör ytterligare steg som tillhandahålls av pipelinen och kör sedan ett valfritt teststeg.

# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

Stöd för Markdown i automatiska testfelmeddelanden

Vi har lagt till Markdown-stöd för felmeddelanden för automatiserade tester. Nu kan du enkelt formatera felmeddelanden för både testkörning och testresultat för att förbättra läsbarheten och underlätta felsökningen av testfel i Azure Pipelines. Markdown-syntaxen som stöds finns här.

Samla in automatiska och användardefinierade metadata från pipelinen

Nu kan du aktivera automatisk och användardefinierad metadatainsamling från pipelineuppgifter. Du kan använda metadata för att framtvinga artefaktprincip i en miljö med hjälp av utvärderingsartefaktkontrollen.

användargränssnittet för Uppdateringar till tjänstanslutningar

Vi har arbetat med en uppdaterad användarupplevelse för att hantera dina tjänstanslutningar. De här uppdateringarna gör tjänstanslutningen modern och överensstämmer med riktningen för Azure DevOps. Vi introducerade det nya användargränssnittet för tjänstanslutningar som en förhandsversionsfunktion tidigare i år. Tack till alla som provat den nya upplevelsen och gett vår värdefulla feedback till oss.

Tillsammans med uppdateringen av användarupplevelsen har vi även lagt till två funktioner som är viktiga för att använda tjänstanslutningar i YAML-pipelines: pipelineauktoriseringar och godkännanden och kontroller.

Den nya användarupplevelsen aktiveras som standard med den här uppdateringen. Du kan fortfarande välja bort förhandsversionen.

Anteckning

Vi planerar att introducera delning mellan projekt av tjänstanslutningar som en ny funktion. Du hittar mer information om delningsupplevelsen och säkerhetsrollerna här.

VM-distributioner med miljöer

En av de mest efterfrågade funktionerna i Miljöer var VM-distributioner. Med den här uppdateringen aktiverar vi virtuella datorresurser i miljöer. Nu kan du orkestrera distributioner på flera datorer och utföra löpande uppdateringar med YAML-pipelines. Du kan också installera agenten på var och en av dina målservrar direkt och köra löpande distribution till dessa servrar. Dessutom kan du använda den fullständiga uppgiftskatalogen på måldatorerna.

En löpande distribution ersätter instanser av den tidigare versionen av ett program med instanser av den nya versionen av programmet på en uppsättning datorer (löpande uppsättning) i varje iteration.

Nedan uppdateras till exempel löpande distributionsuppdateringar upp till fem mål i varje iteration. maxParallel avgör antalet mål som kan distribueras parallellt. Valet står för antalet mål som måste vara tillgängliga när som helst, exklusive de mål som distribueras till. Den används också för att fastställa framgångs- och felvillkoren under distributionen.

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTraffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

Anteckning

Med den här uppdateringen hämtas alla tillgängliga artefakter från den aktuella pipelinen och från de associerade pipelineresurserna endast i deploy livscykel-hook. Du kan dock välja att ladda ned genom att ange Ladda ned pipelineartefaktaktivitet. Det finns några kända luckor i den här funktionen. När du till exempel försöker utföra en fas igen körs distributionen på alla virtuella datorer, inte bara misslyckade mål. Vi arbetar för att täppa till dessa luckor i framtida uppdateringar.

Hoppa över faser i en YAML-pipeline

När du startar en manuell körning kanske du ibland vill hoppa över några steg i pipelinen. Om du till exempel inte vill distribuera till produktion eller om du vill hoppa över distributionen till några miljöer i produktion. Nu kan du göra detta med dina YAML-pipelines.

Den uppdaterade pipelinepanelen för körning visar en lista över faser från YAML-filen och du har möjlighet att hoppa över en eller flera av dessa steg. Du måste vara försiktig när du hoppar över faser. Om ditt första steg till exempel producerar vissa artefakter som behövs för efterföljande steg bör du inte hoppa över den första fasen. Körningspanelen visar en allmän varning när du hoppar över faser som har underordnade beroenden. Det är upp till dig om dessa beroenden är sanna artefaktberoenden eller om de bara finns för sekvensering av distributioner.

Att hoppa över en fas motsvarar att ändra beroendena mellan faserna. Eventuella omedelbara underordnade beroenden för den överhoppade fasen görs beroende av överordnad överordnad fas. Om körningen misslyckas och om du försöker köra om ett misslyckat steg, kommer det försöket också att ha samma överhoppningsbeteende. Om du vill ändra vilka faser som hoppas över måste du starta en ny körning.

Rapportering

Miniatyrbild av inline sprint burndown

Sprint Burndown är tillbaka! För några sprinter sedan tog vi bort den inkontexterade sprintbrännskadan från Sprint Burndown- och Taskboard-rubrikerna. Baserat på din feedback har vi förbättrat och återinfört miniatyrbilden för sprintbrännskadan.

Om du klickar på miniatyrbilden visas omedelbart en större version av diagrammet med ett alternativ för att visa hela rapporten under fliken Analys. Alla ändringar som görs i den fullständiga rapporten återspeglas i diagrammet som visas i rubriken. Nu kan du konfigurera den till att brännas ned baserat på berättelser, artikelpunkter eller antal uppgifter, snarare än bara mängden arbete som återstår.

Skapa en instrumentpanel utan team

Nu kan du skapa en instrumentpanel utan att associera den med ett team. När du skapar en instrumentpanel väljer du typen Projektinstrumentpanel .

En projektinstrumentpanel är som en teaminstrumentpanel, förutom att den inte är associerad med ett team och du kan bestämma vem som kan redigera/hantera instrumentpanelen. Precis som en teaminstrumentpanel är den synlig för alla i projektet.

Alla Azure DevOps-widgetar som kräver en teamkontext har uppdaterats så att du kan välja ett team i konfigurationen. Du kan lägga till dessa widgetar i Projektinstrumentpaneler och välja det specifika team du vill ha.

Anteckning

För anpassade widgetar eller widgetar från tredje part skickar en Projektinstrumentpanel standardteamets kontext till dessa widgetar. Om du har en anpassad widget som förlitar sig på teamkontext bör du uppdatera konfigurationen så att du kan välja ett team.

Nästa steg

Anteckning

De här funktionerna kommer att lanseras 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 dessa funktioner. 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,

Jeff Beehler