Een dashboard maken zonder team - Sprint 162 Update
In de Sprint 162-update van Azure DevOps kunnen we met trots aankondigen dat u een dashboard kunt maken zonder dit te koppelen aan een team. Het dashboard is zichtbaar voor iedereen in het project en u kunt bepalen wie het kan bewerken/beheren.
Daarnaast hebben we de miniatuur van de sprint-burndown toegevoegd. U kunt deze nu configureren voor burndown op basis van verhalen, verhaalpunten of op basis van het aantal taken.
Bekijk de onderstaande lijst met functies voor meer informatie.
Functies
Azure-opslagplaatsen:
Azure Pipelines:
- Bijgewerkte gebruikersinterface voor pijplijnen met meerdere fasen
- De optie VSTest TestResultsDirectory is beschikbaar in de gebruikersinterface van de taak
- Het trefwoord Uitbreiden in pijplijnen gebruiken
- Markdown-ondersteuning in geautomatiseerde testfoutberichten
- Automatische en door de gebruiker opgegeven metagegevens van de pijplijn verzamelen
- gebruikersinterface van Updates naar serviceverbindingen
- VM-implementaties met omgevingen
- Fasen overslaan in een YAML-pijplijn
Rapportage:
Azure-opslagplaatsen
Nieuwe landingspagina's voor webplatformconversie
We hebben de gebruikerservaring van landingspagina's voor opslagplaatsen bijgewerkt om deze modern, snel en mobielvriendelijk 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 aan te kondigen dat we nu ondersteuning bieden voor het markeren van Kotlin-talen in de bestandseditor. Markeren verbetert de leesbaarheid van uw Kotlin-tekstbestand en helpt u snel te scannen op fouten. We hebben prioriteit gegeven aan deze functie op basis van een suggestie van de ontwikkelaarscommunity.
Azure Pipelines
Bijgewerkte gebruikersinterface voor pijplijnen met meerdere fasen
Er is nu standaard een bijgewerkte versie van de gebruikersinterface voor pijplijnen met meerdere fasen beschikbaar. De ervaring met pijplijnen met meerdere fasen brengt verbeteringen en gebruiksgemak met zich mee voor de gebruikersinterface van de pijplijnportal. U kunt uw pijplijnen weergeven en beheren door Pijplijnen te kiezen in het menu aan de linkerkant. Daarnaast kunt u inzoomen en pijplijndetails, uitvoeringsdetails, pijplijnanalyses, taakdetails, logboeken en meer bekijken.
Raadpleeg de documentatie hier voor meer informatie over de gebruikerservaring met pijplijnen met meerdere fasen.
De optie VSTest TestResultsDirectory is beschikbaar in de gebruikersinterface van de taak
De taak VSTest slaat testresultaten en bijbehorende bestanden op in de $(Agent.TempDirectory)\TestResults
map. We hebben een optie toegevoegd aan de taakgebruikersinterface, zodat u een andere map kunt configureren voor het opslaan van testresultaten. Nu kunnen alle volgende taken die de bestanden op een bepaalde locatie nodig hebben, deze gebruiken.
Het trefwoord Uitbreiden in pijplijnen gebruiken
Op dit moment kunnen pijplijnen worden opgenomen in sjablonen, waardoor hergebruik wordt bevorderd en de standaard wordt verkleind. 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 YAML-hoofdbestand kan nu het trefwoord uitbreiden gebruiken om aan te geven dat de hoofdpijplijnstructuur in een ander bestand kan worden gevonden. Hiermee kunt u bepalen welke segmenten kunnen worden uitgebreid of gewijzigd en welke segmenten zijn vastgezet. We hebben ook pijplijnparameters uitgebreid met gegevenstypen om de hooks te wissen die u kunt leveren.
In dit voorbeeld ziet u hoe u eenvoudige hooks kunt opgeven die de auteur van de pijplijn kan gebruiken. De sjabloon voert altijd een build uit, voert optioneel 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 }}
Markdown-ondersteuning in geautomatiseerde testfoutberichten
We hebben Markdown-ondersteuning toegevoegd aan foutberichten voor geautomatiseerde tests. U kunt nu eenvoudig foutberichten opmaken voor zowel de testuitvoering als het testresultaat om de leesbaarheid te verbeteren en de ervaring voor het oplossen van testfouten in Azure Pipelines te vereenvoudigen. De ondersteunde Markdown-syntaxis vindt u hier.
Automatische en door de gebruiker opgegeven metagegevens van de pijplijn verzamelen
U kunt nu het automatisch en door de gebruiker opgegeven verzamelen van metagegevens van pijplijntaken inschakelen. U kunt metagegevens gebruiken om artefactbeleid af te dwingen in een omgeving met behulp van de controle artefact evalueren.
gebruikersinterface van Updates naar serviceverbindingen
We hebben gewerkt aan een bijgewerkte gebruikerservaring voor het beheren van uw serviceverbindingen. Deze updates maken de serviceverbindingservaring modern en consistent met de richting van Azure DevOps. Eerder dit jaar hebben we de nieuwe gebruikersinterface voor serviceverbindingen geïntroduceerd als preview-functie. Bedankt aan iedereen die de nieuwe ervaring heeft geprobeerd en ons hun waardevolle feedback 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 kunt zich nog steeds afmelden voor de preview.
Notitie
We zijn van plan om het delen van serviceverbindingen tussen projecten als een nieuwe mogelijkheid te introduceren. Meer informatie over de ervaring voor delen en de beveiligingsrollen vindt u hier.
VM-implementaties met omgevingen
Een van de meest aangevraagde functies in omgevingen waren VM-implementaties. Met deze update schakelen we virtuele machineresources in in omgevingen. U kunt nu implementaties op meerdere computers organiseren en rolling updates uitvoeren met behulp van YAML-pijplijnen. U kunt de agent ook rechtstreeks op elk van uw doelservers installeren en rolling implementatie naar die servers sturen. 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 worden bijvoorbeeld maximaal vijf doelen in elke iteratie bijgewerkt.
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 waarvoor worden geïmplementeerd. De selectie wordt ook gebruikt om de voorwaarden voor een geslaagde of mislukte 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...
Notitie
Met deze update worden alle beschikbare artefacten van de huidige pijplijn en van de bijbehorende pijplijnresources alleen gedownload in deploy
levenscyclushook. U kunt er echter voor kiezen om te downloaden door de taak Pijplijnartefact downloaden op te geven.
Er zijn enkele bekende hiaten in deze functie. Wanneer u bijvoorbeeld een fase opnieuw probeert, wordt de implementatie opnieuw uitgevoerd op alle VM's, niet alleen op mislukte doelen. We werken eraan om deze hiaten in toekomstige updates te dichten.
Fasen overslaan in een YAML-pijplijn
Wanneer u een handmatige uitvoering start, wilt u soms een paar fasen in uw pijplijn overslaan. Bijvoorbeeld als u 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 Pijplijn uitvoeren bevat een lijst met fasen uit het YAML-bestand. U kunt een of meer van deze fasen overslaan. 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 om te bepalen of deze afhankelijkheden echte artefactafhankelijkheden zijn of dat ze alleen aanwezig zijn voor het sequentiëren van implementaties.
Het overslaan van een fase is gelijk aan het opnieuw koppelen van de afhankelijkheden tussen fasen. Alle directe downstreamafhankelijkheden van de overgeslagen fase zijn afhankelijk van het upstream-bovenliggende bovenliggende element van de overgeslagen fase. Als de uitvoering mislukt en u een mislukte fase opnieuw probeert uit te voeren, heeft die poging ook hetzelfde overslaande gedrag. Als u wilt wijzigen welke fasen worden overgeslagen, moet u een nieuwe uitvoering starten.
Rapporten
Miniatuur van inline-sprint burndown
De Sprint Burndown is terug! Een paar sprint geleden hebben we de in-context sprint burndown verwijderd uit de headers Sprint Burndown en Taskboard. Op basis van uw feedback hebben we de miniatuur van de sprint burndown verbeterd en opnieuw geïntroduceerd.
Als u op de miniatuur klikt, wordt onmiddellijk een grotere versie van de grafiek weergegeven met een optie om het volledige rapport weer te geven op het tabblad Analyse. Eventuele wijzigingen in het volledige rapport worden weergegeven in de grafiek die wordt weergegeven in de koptekst. U kunt deze nu dus configureren voor burndown op basis van verhalen, verhaalpunten of op basis van het aantal taken, in plaats van alleen de resterende hoeveelheid werk.
Een dashboard maken zonder team
U kunt nu een dashboard maken zonder dit te koppelen aan een team. Selecteer bij het maken van een dashboard het type Projectdashboard .
Een projectdashboard is net 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 in hun configuratie kunt selecteren. U kunt deze widgets toevoegen aan projectdashboards en het gewenste team selecteren.
Notitie
Voor aangepaste widgets of widgets van derden geeft een projectdashboard de context van het standaardteam door aan deze widgets. Als u een aangepaste widget hebt die afhankelijk is van teamcontext, moet u de configuratie bijwerken zodat u een team kunt selecteren.
Volgende stappen
Notitie
Deze functies worden in de komende twee tot drie weken uitgerold.
Ga naar Azure DevOps en neem een kijkje.
Feedback geven
We horen graag wat u vindt van deze functies. Gebruik het menu Help om een probleem te melden of een suggestie te doen.
U kunt ook advies krijgen en uw vragen worden beantwoord door de community op Stack Overflow.
Met vriendelijke groet,
Jeff Beehler