Een dashboard maken zonder een team - Sprint 162 Update

In de Sprint 162-update van Azure DevOps zijn we verheugd om aan te kondigen dat u een dashboard kunt maken zonder dit aan een team te koppelen. Het dashboard is zichtbaar voor iedereen in het project en u kunt bepalen wie het kan bewerken/beheren.

Daarnaast hebben we de sprint-burndown-afbeelding toegevoegd. U kunt het nu configureren om te burn-down op basis van verhalen, verhaalpunten of het aantal taken.

Bekijk de functies lijst hieronder voor meer informatie.

Features

Azure Repos

• Nieuwe landingspagina's voor conversie van webplatforms
• Ondersteuning voor Kotlin-taal

Azure Pipelines:

• Gebruikersinterface voor pijplijnen met meerdere fasen bijgewerkt
• De optie VSTest TestResultsDirectory is beschikbaar in de gebruikersinterface van de taak
• Gebruik het sleutelwoord extends in pijplijnen
• Markdown-ondersteuning in geautomatiseerde testfoutberichten
• Automatische en door de gebruiker opgegeven metagegevens van pijplijn verzamelen
• Updates voor de gebruikersinterface voor serviceverbindingen
• VM-implementaties met omgevingen
• Fasen in een YAML-pijplijn overslaan

Berichtgeving:

• Inline sprint burndown verloopgrafiek miniatuur
• Een dashboard maken zonder een team

Azure Repos

Nieuwe landingspagina's voor webplatformconversie

We hebben de gebruikerservaring van de startpagina's van opslagplaatsen bijgewerkt om deze modern, snel en geschikt voor mobiele apparaten te maken. Hier volgen twee voorbeelden van de pagina's die zijn bijgewerkt. In toekomstige updates blijven we andere pagina's bijwerken.

Webervaring:

Mobiele ervaring:

Ondersteuning voor Kotlin-taal

We zijn verheugd om aan te kondigen dat we nu ondersteuning bieden voor kotlin-taalmarkeringen in de bestandseditor. Markeren verbetert de leesbaarheid van uw Kotlin-tekstbestand en helpt u snel te scannen om fouten te vinden. We hebben prioriteit gegeven aan deze functie op basis van een suggestie van de ontwikkelaarscommunity.

Azure-pipelines

Bijgewerkte gebruikersinterface voor meerfasige pijplijnen

Een bijgewerkte versie van de gebruikersinterface voor pijplijnen met meerdere fasen is nu standaard beschikbaar. De ervaring met pijplijnen met meerdere fasen biedt verbeteringen en gebruiksgemak in de gebruikersinterface van de portal van de pijplijn. U kunt uw pijplijnen bekijken en beheren door Pijplijnen te kiezen in het menu aan de linkerkant. Daarnaast kunt u inzoomen en de details van de pijplijn bekijken, details uitvoeren, pijplijnanalyses, taakdetails, logboeken en meer.

Zie de documentatie hier voor meer informatie over de gebruikerservaring voor pijplijnen met meerdere fasen.

De optie VSTest TestResultsDirectory is beschikbaar in de gebruikersinterface van de taak

De VSTest-taak slaat testresultaten en bijbehorende bestanden op in de $(Agent.TempDirectory)\TestResults map. We hebben een optie toegevoegd aan de gebruikersinterface van de taak, zodat u een andere map kunt configureren om testresultaten op te slaan. Alle volgende taken die de bestanden op een bepaalde locatie nodig hebben, kunnen deze nu gebruiken.

Het extends-trefwoord gebruiken in pijplijnen

Op dit moment kunnen pijplijnen worden opgenomen in sjablonen, waardoor hergebruik wordt bevorderd en overbodige code wordt verminderd. De algehele structuur van de pijplijn is nog steeds gedefinieerd door het YAML-hoofdbestand. Met deze update hebben we een meer gestructureerde manier toegevoegd om pijplijnsjablonen te gebruiken. Een root-YAML-bestand kan nu het trefwoord extends gebruiken om aan te geven dat de hoofdpijplijnstructuur in een ander bestand kan worden gevonden. Hierdoor hebt u de controle over welke segmenten kunnen worden uitgebreid of gewijzigd en welke segmenten zijn vastgezet. We hebben de parameters voor pijplijnen verbeterd met gegevenstypen, zodat het duidelijk is welke haken u kunt opgeven.

In dit voorbeeld wordt geïllustreerd hoe u eenvoudige hooks kunt aanbieden die de auteur van de pijplijn kan gebruiken. De sjabloon voert altijd een build uit, voert eventueel extra stappen uit die door de pijplijn worden geleverd en voert vervolgens een optionele teststap uit.

# 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 }}

Ondersteuning voor Markdown in geautomatiseerde testfoutberichten

We hebben Markdown-ondersteuning toegevoegd aan foutberichten voor geautomatiseerde tests. U kunt nu eenvoudig foutberichten opmaken voor zowel testuitvoering als testresultaat om de leesbaarheid te verbeteren en de ervaring voor het oplossen van problemen met testfouten in Azure Pipelines te vereenvoudigen. De ondersteunde Markdown-syntaxis vindt u hier.

Automatische en door de gebruiker opgegeven metagegevens uit de pijplijn verzamelen

U kunt nu automatische en door de gebruiker opgegeven metagegevensverzameling inschakelen vanuit pijplijntaken. U kunt metagegevens gebruiken om artefactbeleid af te dwingen voor een omgeving door de artefactevaluatiecontrole te gebruiken.

Updates voor de gebruiker interface voor serviceverbindingen

We hebben gewerkt aan een bijgewerkte gebruikerservaring om uw serviceverbindingen te beheren. Deze updates maken de serviceverbindingservaring modern en consistent met de richting van Azure DevOps. We hebben de nieuwe gebruikersinterface voor serviceverbindingen geïntroduceerd als preview-functie eerder dit jaar. Dankzij iedereen die de nieuwe ervaring heeft geprobeerd en hun waardevolle feedback aan ons heeft gegeven.

Naast het vernieuwen van de gebruikerservaring hebben we ook twee mogelijkheden toegevoegd die essentieel zijn voor het gebruik van serviceverbindingen in YAML-pijplijnen: pijplijnautorisaties en goedkeuringen en controles.

De nieuwe gebruikerservaring wordt standaard ingeschakeld met deze update. U hebt nog steeds de mogelijkheid om u af te wijzen voor de preview.

VM-implementaties met omgevingen

Een van de meest aangevraagde functies in omgevingen was VM-implementaties. Met deze update stellen we virtuele machineresources beschikbaar in omgevingen. U kunt nu implementaties op meerdere computers organiseren en rolling updates uitvoeren met behulp van YAML-pijplijnen. Installeer de agent ook rechtstreeks op elk van uw doelservers en voer een gefaseerde uitrol naar die servers uit. Daarnaast kunt u de volledige taakcatalogus op uw doelcomputers gebruiken.

Een rolling implementatie vervangt exemplaren van de vorige versie van een toepassing door exemplaren van de nieuwe versie van de toepassing op een set machines (rolling set) in elke iteratie.

Hieronder vindt u bijvoorbeeld updates voor rolling implementaties van maximaal vijf doelen in elke iteratie. maxParallel bepaalt het aantal doelen dat parallel kan worden geïmplementeerd. De selectie houdt rekening met het aantal doelen dat op elk gewenst moment beschikbaar moet blijven, met uitzondering van de doelen waarop wordt geïmplementeerd. Het wordt ook gebruikt om de voorwaarden voor succes en fouten tijdens de implementatie te bepalen.

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...

Fasen in een YAML-pijplijn overslaan

Wanneer u een handmatige uitvoering start, wilt u soms een paar fasen in uw pijplijn overslaan. Als u bijvoorbeeld niet wilt implementeren in productie of als u de implementatie naar een paar omgevingen in productie wilt overslaan. U kunt dit nu doen met uw YAML-pijplijnen.

Het bijgewerkte deelvenster pijplijnuitvoering bevat een lijst met fasen uit het YAML-bestand en u hebt de mogelijkheid om een of meer van deze fasen over te slaan. Wees voorzichtig bij het overslaan van fasen. Als uw eerste fase bijvoorbeeld bepaalde artefacten produceert die nodig zijn voor volgende fasen, moet u de eerste fase niet overslaan. In het uitvoeringsvenster wordt een algemene waarschuwing weergegeven wanneer u fasen overslaat die downstreamafhankelijkheden hebben. Het is aan u overgelaten of deze afhankelijkheden werkelijke artefactafhankelijkheden zijn of dat ze alleen aanwezig zijn voor de volgorde van implementaties.

Het overslaan van een fase is gelijk aan het opnieuw draaien van de afhankelijkheden tussen fasen. Eventuele directe downstreamafhankelijkheden van de overgeslagen fase worden afhankelijk gemaakt van de bovenliggende fase die zich stroomopwaarts bevindt van de overgeslagen fase. Als de uitvoering mislukt en u probeert een mislukte fase opnieuw uit te voeren, zal die poging ook hetzelfde gedrag van overslaan vertonen. Als u wilt wijzigen welke fasen worden overgeslagen, moet u een nieuwe uitvoering starten.

Berichtgeving

Inline sprint burndown miniatuurafbeelding

De Sprint Burndown is terug! Een paar sprints geleden hebben we de in-context sprint burndown verwijderd uit de headers Sprint Burndown en Taskboard. Op basis van uw feedback hebben we de burndown-thumbnail voor sprints verbeterd en heringevoerd.

Als u op de miniatuur klikt, wordt direct een grotere versie van de grafiek weergegeven met een optie om het volledige rapport weer te geven op het tabblad Analyse. Wijzigingen in het volledige rapport worden doorgevoerd in de grafiek die in de koptekst wordt weergegeven. U kunt deze nu configureren voor burndown op basis van verhalen, verhaalpunten of het aantal taken, in plaats van alleen de hoeveelheid resterende hoeveelheid werk.

Een dashboard maken zonder een team

U kunt nu een dashboard maken zonder het te koppelen aan een team. Wanneer u een dashboard maakt, selecteert u het type Projectdashboard .

Een projectdashboard is net als een teamdashboard, behalve dat het niet is gekoppeld aan een team en u kunt bepalen wie het dashboard kan bewerken/beheren. Net als een teamdashboard is het zichtbaar voor iedereen in het project.

Alle Azure DevOps-widgets waarvoor een teamcontext is vereist, zijn bijgewerkt, zodat u een team kunt selecteren in hun configuratie. U kunt deze widgets toevoegen aan Project Dashboards en het gewenste team selecteren.

Volgende stappen

Ga naar Azure DevOps en kijk eens.

Feedback geven

We horen graag wat u van deze functies vindt. Gebruik het Help-menu om een probleem te melden of een suggestie op te geven.

U kunt ook advies krijgen en uw vragen beantwoorden door de community op Stack Overflow.

Bedankt

Jeff Beehler