Organisatiefacturering beheren in Azure DevOps - Sprint 150 Update

In de Sprint 150-update van Azure DevOps hebben we de mogelijkheid toegevoegd om facturering voor uw organisatie te beheren in onze portal.

Op het nieuwe tabblad Facturering kunt u het Azure-abonnement kiezen dat u voor facturering gebruikt en voor extra gebruikers betalen. U hoeft niet langer naar de Visual Studio Marketplace of de Azure Portal te gaan om facturering te beheren.

Bekijk de onderstaande lijst met functies voor meer informatie.

Functies

Algemeen:

• Algemene beschikbaarheid van thema Donker
• Facturering voor uw organisatie beheren vanuit Azure DevOps

Azure Boards:

• Query's uitvoeren op basis van Azure Active Directory-groepen
• Het bord van uw team delen met behulp van een badge
• Query voor werk ten opzichte van het begin van de dag, week, maand of jaar
• Queryresultaten exporteren naar een CSV-bestand

Azure-opslagplaatsen:

• Nieuwe samenvoegingstypen voor het voltooien van pull-aanvragen

Azure Pipelines:

• Kubernetes-manifesttaak
• Upgrades naar Docker-taak
• Installatieprogramma voor kubectl-hulpprogramma
• verbinding met de Docker-registerservice Azure Container Registry
• cgroup-ondersteuning op gehoste Ubuntu-pool
• Eenmaal uitgevoerde agent
• Ondersteuning voor Visual Studio 2019 (VS2019) in Visual Studio-testtaak
• Update van gebruikersinterface van agentgroep
• Taak assistent voor het bewerken van YAML-bestanden
• Updates van installatiekopieën voor gehoste pijplijnen
• Verbeteringen in ServiceNow-integratie
• Ondersteuning voor Azure PowerShell Az-module
• Verbeteringen in resourceautorisatie
• Vereenvoudigd bewaarbeleid voor build-pijplijnen
• Pijplijnartefacten die automatisch worden opgehaald in de release
• Updates van cobertura-codedekkingsrapport

Rapportage:

• Rapporten over mislukte build en duur
• Algemene beschikbaarheid van Analytics

Wiki:

• Meldingen op wikipagina's

Beheer:

• Facturering voor uw organisatie beheren vanuit Azure DevOps

Algemeen

Algemene beschikbaarheid van thema Donker

Afgelopen oktober hebben we de openbare preview van het donkere thema uitgebracht als onderdeel van de nieuwe navigatie. Na enkele maanden in preview, het luisteren naar feedback en het afstemmen van de ervaring, zijn we verheugd om de algemene beschikbaarheid van het donkere thema aan te kondigen.

Facturering voor uw organisatie beheren vanuit Azure DevOps

We zijn blij te kunnen aankondigen dat u nu de facturering van uw organisatie kunt beheren vanuit de Azure DevOps-portal. Beheerders hoeven facturering niet meer in te stellen via de Azure Portal. Als u de factureringsinstellingen wilt beheren, gaat u naar Uw organisatie-instellingen en selecteert u Facturering.

Hieronder ziet u een lijst met instellingen die u kunt beheren op het tabblad Facturering .

1. U kunt een Azure-abonnement kiezen dat u wilt gebruiken voor facturering.

   

2. U kunt het Azure-abonnement wijzigen dat uw organisatie voor facturering gebruikt door een ander abonnement te selecteren. Voorheen moest u de facturering verwijderen en vervolgens zorgvuldig hetzelfde niveau opnieuw kopen voor elk van uw betaalde resources (basisgebruikers, gebruikers van pakketbeheer, door MS gehoste pijplijnen, enzovoort). Dit proces was omslachtig en foutgevoelig. U kunt nu het Azure-abonnement wijzigen dat uw organisatie voor facturering gebruikt door een ander abonnement te selecteren en op Opslaan te klikken.

   

3. U hoeft niet langer naar Visual Studio Marketplace te gaan om de factureringsinstellingen te beheren. We hebben de mogelijkheid toegevoegd om te betalen voor extra gebruikers van Basic, Test Manager en Package Management (Azure Artifacts). U kunt het aantal gebruikers dat uw organisatie betaalt verhogen of verlagen via het nieuwe tabblad Facturering .

   

Azure Boards

Query's uitvoeren op basis van Azure Active Directory-groepen

Met de toegenomen acceptatie van Azure Active Directory en het gebruik van groepen voor het beheren van beveiliging, zijn teams steeds meer op zoek naar manieren om deze groepen in Azure Boards te gebruiken. Naast het uitvoeren van query's op werkitems die zijn toegewezen of gewijzigd door specifieke personen met behulp van de operators In groep of Niet in groep , kunt u nu ook rechtstreeks Azure Active Directory-groepen gebruiken.

Zie de documentatie voor queryoperators voor meer informatie.

Het bord van uw team delen met behulp van een badge

Het LEESMIJ-bestand van de opslagplaats is vaak de thuisbasis van uw projectteam voor informatie over hoe u een bijdrage kunt leveren aan en hoe u uw oplossing kunt gebruiken. U kunt nu, net als bij een build- of implementatiestatus in Azure Pipelines, een badge voor het bord van uw team toevoegen in Azure Boards. U kunt de badge zo configureren dat alleen de kolommen In uitvoering of alle kolommen worden weergegeven, en de badge zelfs openbaar zichtbaar maken als uw project open source is.

Als uw LEESMIJ is gebaseerd op Markdown, kunt u gewoon de voorbeeld-Markdown kopiëren vanaf de pagina met instellingen voor statusbadges en deze in uw bestand plakken.

Query voor werk ten opzichte van het begin van de dag, week, maand of jaar

Hoewel teams zich vaak richten op werk binnen de context van wat er komt of op basis van sprint-iteraties, is het vaak interessant om terug te kijken naar het werk door de lens van de agenda om te rapporteren over al het werk dat de afgelopen maand of in het eerste kwartaal van het jaar is gebeurd. U kunt nu de volgende nieuwe set @StartOf macro's gebruiken, samen met een datumveld om query's uit te voeren op basis van het begin van de dag, week, maand of jaar:

• @StartOfYear
• @StartOfMonth
• @StartOfWeek
• @StartOfDay

Elk van deze macro's accepteert ook een nieuwe wijzigingsreeks waarmee u de gegevens op verschillende datumeenheden kunt verplaatsen. U kunt bijvoorbeeld een query schrijven om alle werkitems te vinden die in het eerste kwartaal van dit jaar zijn voltooid door een query uit te voeren op Statuswijzigingsdatum >= @StartOfYear en Statuswijzigingsdatum <= @StartOfYear(“+3M”). Zie de documentatie voor querymacro's voor meer informatie.

Queryresultaten exporteren naar een CSV-bestand

U kunt queryresultaten nu rechtstreeks exporteren naar een CSV-bestand van internet.

Azure-opslagplaatsen

Nieuwe samenvoegingstypen voor het voltooien van pull-aanvragen

U hebt nu meer opties bij het samenvoegen van de wijzigingen van een pull-aanvraag naar de doelbranch. We hebben ondersteuning toegevoegd voor twee van de meest aangevraagde functies in de ontwikkelaarscommunity: Fast-Forward samenvoegen en Semi-lineair samenvoegen (ook wel 'Rebase and Merge' genoemd).

U ziet nu deze nieuwe opties die beschikbaar zijn in het dialoogvenster Pull-aanvraag voltooien :

Op de bijgewerkte beleidsbeheerpagina kunnen beheerders bepalen welke samenvoegstrategieën zijn toegestaan voor een vertakking of map met vertakkingen.

Notitie

Bestaande beleidsregels worden nog steeds afgedwongen. Als uw vertakking bijvoorbeeld momenteel een beleid 'alleen samenvoegen' heeft, moet u dat beleid bewerken om de nieuwe samenvoegstrategieën te kunnen gebruiken.

Er zijn enkele situaties waarin het opnieuw maken van een basis tijdens het voltooien van de pull-aanvraag niet mogelijk is:

• Als een beleid op de doelvertakking het gebruik van rebase-strategieën verbiedt, hebt u de machtiging 'Beleid voor vertakking negeren' nodig.
• Als de bronvertakking van de pull-aanvraag beleidsregels heeft, kunt u deze niet opnieuw baseeren. Als u de bronvertakking opnieuw uitvoert, wordt de bronvertakking gewijzigd zonder het goedkeuringsproces voor beleid te doorlopen.
• Als u de uitbreiding voor samenvoegingsconflicten hebt gebruikt om samenvoegingsconflicten op te lossen. Conflictoplossing die wordt toegepast op een samenvoeging in drie richtingen zijn zelden geslaagd (of zelfs geldig) wanneer alle doorvoeringen in een pull-aanvraag één voor één opnieuw worden gemaakt.

In al deze gevallen hebt u nog steeds de mogelijkheid om uw vertakking lokaal opnieuw te maken en naar de server te pushen of uw wijzigingen samen te voegen wanneer u de pull-aanvraag voltooit.

Azure Pipelines

Kubernetes-manifesttaak

We hebben een nieuwe taak toegevoegd aan onze release-pijplijnen om het implementatieproces naar Kubernetes-clusters met behulp van manifestbestanden te vereenvoudigen. Deze taak biedt de volgende voordelen in vergelijking met het gebruik van kubectl binary in scripts:

• Artefactvervanging: de implementatieactie neemt als invoer een lijst met containerinstallatiekopieën die samen met hun tags of digests kunnen worden opgegeven. Dit wordt vervangen door de niet-sjabloonversie van de manifestbestanden voordat deze wordt toegepast op het cluster om ervoor te zorgen dat de juiste versie van de installatiekopie wordt opgehaald door de knooppunten van het cluster.

• Manifeststabiliteit: de implementatiestatus wordt gecontroleerd voor de Kubernetes-objecten die zijn geïmplementeerd om stabiliteitscontroles op te nemen tijdens het berekenen van de taakstatus als geslaagd/mislukt.

• Aantekeningen bij traceerbaarheid: aantekeningen worden toegevoegd aan de geïmplementeerde Kubernetes-objecten om traceerbaarheidsinformatie over de oorspronkelijke organisatie, het project, de pijplijn en de uitvoering over te slaan.

• Manifest bakken: met de bakactie van de taak kunt u Helm-grafieken in Kubernetes-manifestbestanden bakken, zodat ze op het cluster kunnen worden toegepast.

• Implementatiestrategie: het kiezen van een canary-strategie met implementatieactie leidt tot het maken van het gewenste percentage workloads met achtervoegsel -basislijn en -canary , zodat ze tijdens een ManualIntervention taak kunnen worden vergeleken voordat de actie verhogen/negeren van de taak wordt gebruikt om de versie te voltooien die moet worden bewaard.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)
    containers: |
      nginx: 1.7.9

Upgrades naar Docker-taak

We hebben de Docker-taak bijgewerkt om de ontwerpervaring voor pijplijnen te vereenvoudigen. De opdracht buildAndPush kan nu worden gebruikt om meerdere tags te bouwen voor een specifieke containeropslagplaats en deze in één stap naar meerdere containerregisters te pushen. De taak kan docker-registerserviceverbindingen gebruiken voor aanmelding bij containerregisters. Traceability metadata about source repository, commit and build provenance are added as labels to the images built using this task.

steps:
- task: Docker@2
  displayName: Container registry login - ACR1 service connection
  inputs:
    command: login
    containerRegistry: acr1
- task: Docker@2
  displayName: Container registry login - ACR2 service connection
  inputs:
    command: login
    containerRegistry: acr2
- task: Docker@2
  displayName: Build and push images
  inputs:
    repository: test
    tags: |
      d1
      d2

Installatieprogramma voor kubectl-hulpprogramma

We hebben een nieuwe taak toegevoegd waarmee u een specifieke versie van het binaire Kubectl-bestand op de agents kunt installeren. De meest recente en semver-versietekenreeksen zoals 'v1.14.0' worden geaccepteerd als geldige waarden voor de invoer van Kubectl Version Spec.

Verbinding met De Azure-containerregister in docker-registerservice

U kunt nu een Docker-registerserviceverbinding maken vanaf de instellingenpagina van uw project. Als u de verbinding wilt maken, kiest u een Azure-containerregister in een van de abonnementen die zijn gekoppeld aan uw Azure Active Directory-identiteit (Azure AD). Alle taken waarvoor serviceverbindingen met containerregisters nodig zijn, zoals Docker@2 en KubernetesManifest@0 , ondersteunen één manier om een verbinding op te geven.

cgroup-ondersteuning op gehoste Ubuntu-pool

Wanneer het geheugengebruik in Linux te hoog wordt, beëindigt de kernel sommige processen om de rest te beveiligen. Als het proces van de Azure Pipelines-agent is geselecteerd voor beëindiging, mislukt de uitvoering van de pijplijn met een foutbericht over het verlies van de communicatie met de agent. In de door Microsoft gehoste Ubuntu-pool hebben we de kans verkleind dat de agent wordt beëindigd door stappen uit te voeren in een aangepaste cgroup. Hoewel uw pijplijn nog steeds kan mislukken als u het beschikbare geheugen overschrijdt, is de kans groter dat het agentproces het overleeft en de fout correct rapporteert. Als u een privé-Linux-agent uitvoert, hebben we de instellingen gepubliceerd die we gebruiken, zodat u een vergelijkbare installatie kunt overwegen.

Eenmaal uitgevoerde agent

Als u infrastructuur zoals Azure Container Instances gebruikt om elastische privéagenten uit te voeren, wilt u vaak dat elke agent slechts één taak accepteert voordat deze wordt verwijderd. Tot nu toe was dit niet eenvoudig omdat u de agent moest beëindigen (waardoor mogelijk een fout werd gerapporteerd) of het risico moest accepteren dat een agent een andere taak zou kunnen ontvangen voordat u deze kon afsluiten. Met deze update hebben we de vlag --once toegevoegd aan de agentconfiguratie. Wanneer u de agent op deze manier configureert, accepteert deze slechts één taak en wordt vervolgens zichzelf afgesloten.

Ondersteuning voor Visual Studio 2019 (VS2019) in Visual Studio Test-taak

We hebben ondersteuning voor VS2019 toegevoegd aan de Visual Studio Test-taak in pijplijnen. Als u tests wilt uitvoeren met behulp van het testplatform voor VS2019, selecteert u de opties Nieuwste of Visual Studio 2019 in de vervolgkeuzelijst Platformversie testen.

Update van gebruikersinterface van agentgroep

De beheerpagina voor agentpools in projectinstellingen is bijgewerkt met een nieuwe gebruikersinterface. U kunt nu eenvoudig alle taken zien die in een pool worden uitgevoerd. Daarnaast kunt u leren waarom een taak niet wordt uitgevoerd.

Taak assistent voor het bewerken van YAML-bestanden

We blijven veel feedback ontvangen waarin wordt gevraagd om het bewerken van YAML-bestanden voor pijplijnen gemakkelijker te maken. In de vorige updates hebben we intelliSense-ondersteuning toegevoegd. Nu voegen we een taak toe assistent aan de YAML-editor. Hiermee hebt u dezelfde vertrouwde ervaring voor het toevoegen van een nieuwe taak aan een YAML-bestand als in de klassieke editor. Deze nieuwe assistent ondersteunt de meeste veelvoorkomende taakinvoertypen, zoals selectielijsten en serviceverbindingen. Als u de nieuwe taak assistent wilt gebruiken, selecteert u Bewerken in een YAML-pijplijn en selecteert u vervolgens de assistent Taak.

Updates van installatiekopieën voor gehoste pijplijnen

We zijn verheugd om updates voor de gehoste macOS-pool voor OS X Mojave (10.4) aan te kondigen, die ook ondersteuning voor Xcode 10.2 bevatten. Als uw ontwerppijplijnen gebruikmaken van de gehoste macOS-pool , worden uw pijplijnen automatisch geupgraded naar Mojave. Als u OS X High Sierra (10.3) wilt blijven gebruiken, wijzigt u de pool waarop uw builds worden uitgevoerd in Gehoste macOS High Sierra.

Als u YAML gebruikt, kunt u de volgende nieuwe vmImage-labels gebruiken:

• Afbeeldingslabel dat altijd verwijst naar de nieuwste versie van macOS, momenteel 10.4

vmImage: 'macOS-latest'

• Dit installatiekopieënlabel is specifiek gericht op mac OS 10.4 als u er zeker van wilt zijn dat uw pijplijn wordt uitgevoerd met Mojave

vmImage: 'macOS-10.4'

• Afbeeldingslabel dat specifiek gericht is op mac OS 10.3 als u er zeker van wilt zijn dat uw pijplijn wordt uitgevoerd op High Sierra

vmImage: 'macOS-10.3'

We hebben ook updates aangebracht voor de installatiekopie van Windows Server 2019 voor uw gehoste Azure-pijplijnen. De nieuwste releases vindt u hier. Deze update bevat nieuwe versies van de VS2019 Preview, Docker, PowerShell Core, Node.js, npm en andere.

Ga naar de opslagplaats Voor het genereren van installatiekopieën op GitHub voor meer informatie over de inhoud van onze gehoste macOS VM-installatiekopieën en voor meer informatie over de hulpprogramma's die beschikbaar zijn op onze installatiekopieën.

Verbeteringen in ServiceNow-integratie

Afgelopen december hebben we de ServiceNow Change Management-integratie met release-pijplijnen uitgebracht. Een belangrijke mogelijkheid voor samenwerking tussen teams, waardoor elk team een service naar keuze kon gebruiken en een effectieve end-to-end-levering kon krijgen. Met deze update hebben we de integratie verbeterd om alle soorten wijzigingen (normaal, standaard en nood) te ondersteunen. Daarnaast kunt u nu de poort opgeven die wordt gebruikt om een nieuwe wijzigingsaanvraag te maken met behulp van een bestaande sjabloon, volgens het ITSM-proces dat in uw organisatie is gevolgd. Ten slotte kunt u ook releases gateen op basis van bestaande wijzigingsaanvragen. Hierdoor kunt u CD gebruiken, zonder dat u het proces hoeft te wijzigen dat door uw IT-teams wordt aanbevolen.

Ondersteuning voor Azure PowerShell Az-module

Azure PowerShell biedt een set cmdlets die u kunt gebruiken om Azure-resources te beheren vanaf de opdrachtregel. Afgelopen december kwam de Azure PowerShell Az-module beschikbaar en is nu de beoogde module voor het beheren van uw Azure-resources.

Eerder hebben we geen ondersteuning geboden voor de Azure PowerShell Az-module in onze gehoste agents. Met de nieuwe Azure PowerShell taakversie 4.* in build- en release-pijplijnen hebben we ondersteuning toegevoegd voor de nieuwe Az-module voor alle platforms. Azure PowerShell taakversie 3.* blijft ondersteuning bieden voor de AzureRM-module. Als u echter op de hoogte wilt blijven van de nieuwste Azure-services en -functies, raden we u aan zo snel mogelijk over te schakelen naar de Azure PowerShell taakversie 4.* .

De Az-module heeft een compatibiliteitsmodus om u te helpen bestaande scripts te gebruiken terwijl u deze bijwerkt om de nieuwe syntaxis te gebruiken. Gebruik de Enable-AzureRmAlias opdracht om compatibiliteit voor de Az-module in te schakelen. Met aliassen kunt u de oude cmdlet-namen gebruiken met az-module. Meer informatie over het migreren van de Azure RM-module naar de Azure PowerShell Az-module vindt u hier.

Notitie

Als u privéagents gebruikt, moet u de Az-module installeren op uw agentcomputer.

Zie de documentatie hier voor meer informatie over de module Azure PowerShell Az.

Verbeteringen in resourceautorisatie

We moesten beveiliging bieden voor beveiligde resources (bijvoorbeeld serviceverbindingen, variabele groepen, agentgroepen, beveiligde bestanden) wanneer ernaar wordt verwezen in een YAML-bestand. Tegelijkertijd willen we het voor u eenvoudiger maken om pijplijnen in te stellen en te gebruiken die gebruikmaken van dit type resources voor niet-productiescenario's. Eerder hebben we een instelling toegevoegd om een resource te markeren als 'geautoriseerd voor gebruik in alle pijplijnen'.

Met deze update maken we het eenvoudiger voor u om een probleem met resourceautorisatie op te lossen, zelfs als u een resource niet als zodanig hebt gemarkeerd. Wanneer in de nieuwe ervaring een build mislukt vanwege een resourceautorisatiefout, ziet u een optie om het gebruik van deze resources in de pijplijn expliciet te autoriseren en vervolgens verder te gaan. Teamleden met machtigingen voor het autoriseren van resources kunnen deze actie rechtstreeks vanuit een mislukte build voltooien.

Vereenvoudigd bewaarbeleid voor build-pijplijnen

We hebben het retentiemodel vereenvoudigd voor alle build-pijplijnen, inclusief YAML-builds. Er is een nieuwe instelling op projectniveau waarmee u kunt bepalen hoeveel dagen u de builds van elke pijplijn wilt behouden en hoeveel dagen u de artefacten van elke build wilt behouden. Als u de klassieke editor hebt gebruikt om uw build-pijplijn te maken, blijven de oudere bewaarinstellingen behouden, maar nieuwere pijplijnen gebruiken de nieuwe instellingen. U kunt retentie beheren op de pagina pijplijninstellingen van projectinstellingen.

Pijplijnartefacten die automatisch worden opgehaald in de release

Als de build-pijplijn die is gekoppeld aan een release eerder artefacten had gepubliceerd met behulp van de taak Pijplijnartefact publiceren , werden de artefacten niet automatisch opgehaald in de release. In plaats daarvan moest u expliciet een taak Pijplijnartefact downloaden toevoegen in de release-pijplijn om de artefacten te downloaden.

Nu worden alle pijplijnartefacten die door de build-pijplijn zijn gepubliceerd, automatisch gedownload en beschikbaar gesteld in de release. U kunt ook het downloaden van uw pijplijnartefact aanpassen vanuit de fase-eigenschappen van de release-pijplijn.

Updates van cobertura-codedekkingsrapport

Voorheen was het nodig om zowel het XML-overzicht als een HTML-rapportbestand op te geven wanneer u tests in pijplijn uitvoerde en codedekkingsresultaten naar Azure DevOps hebt gepubliceerd. Daarnaast zijn stijlen in de HTML-rapporten verwijderd voordat ze werden weergegeven op het tabblad Codedekking. Dit verwijderen van stijl was vanuit het oogpunt van beveiliging noodzakelijk, omdat willekeurige HTML-bestanden konden worden geüpload.

Met deze update hebben we deze beperkingen voor Cobertura-dekkingsrapporten opgelost. Wanneer u codedekkingsrapporten publiceert, hoeft u geen HTML-bestanden meer op te geven. Rapporten worden automatisch gegenereerd en weergegeven met de juiste stijl op het tabblad Codedekking. Deze mogelijkheid maakt gebruik van het open source hulpprogramma ReportGenerator.

Rapporten

Rapporten over mislukte build en duur

Het is belangrijk om over metrische gegevens en inzichten te beschikken om de doorvoer en stabiliteit van uw pijplijn continu te verbeteren. Als eerste stap om u pijplijnanalyses te bieden, hebben we twee rapporten toegevoegd om u metrische gegevens en inzichten over uw pijplijnen te geven.

1. In het foutenrapport worden de slagingsfrequentie en de fouttrend weergegeven. Daarnaast wordt ook de trend van mislukte taken weergegeven om inzicht te krijgen in welke taak bijdraagt aan het maximum aantal fouten.

   

2. Het duurrapport bevat de pijplijnduur samen met de trend.

   

Algemene beschikbaarheid van Analytics

We zijn verheugd om aan te kondigen dat de volgende Analytics-functies zonder extra kosten worden opgenomen in Azure DevOps.

1. De Analytics-widgets zijn configureerbare modules waarmee gegevens op een dashboard worden weergegeven en waarmee u de voortgang van uw werk kunt volgen. De widgets die zijn opgenomen, zijn de volgende:

   • Burndown- en Burnup-grafieken bewaken de voortgang van een reeks werk binnen een bepaalde periode.

     

   • Cyclustijd en doorlooptijd om te visualiseren hoe werk zich door de ontwikkelingscyclus van uw team beweegt

     

   • Cumulatief stroomdiagram (CFD) houdt werkitems bij terwijl ze zich door verschillende statussen ontwikkelen.

     

   • Velocity houdt bij hoe een team waarde levert voor meerdere sprints.

     

   • Testresultaten Trend voor het bewaken van testtrends, het detecteren van fout- en duurpatronen voor tests via één of meerdere pijplijnen.

     

2. In het product voegen we het meest mislukte testrapport toe om inzicht te krijgen in de belangrijkste mislukte tests in uw pijplijn om de betrouwbaarheid van de pijplijn te verbeteren en de testschuld te verminderen.

   

We blijven ook Power BI-integratie bieden via analyseweergaven en directe toegang tot ons OData-eindpunt in preview voor alle Azure DevOps Services-klanten.

Als u de Analytics Marketplace-extensie gebruikt, kunt u Analytics blijven gebruiken zoals voorheen en hoeft u geen aanvullende stappen te volgen. Dit betekent dat we de Analytics Marketplace-extensie voor gehoste klanten zullen afschappen.

Het Azure DevOps Analytics-aanbod is de toekomst van rapportage en we blijven investeren in nieuwe functies die worden aangestuurd door Analytics. Meer informatie over Analytics vindt u in de onderstaande koppelingen.

• Overzichtsdocumentatie voor analyse

• Analysewidgets

• Meest mislukte testrapport

• Power BI-integratie

• OData-eindpunt

• Azure DevOps Analytics

Wiki

Meldingen op wikipagina's

Tot nu toe wist u niet wanneer de inhoud op een wikipagina werd gewijzigd. U kunt nu wikipagina's volgen om via e-mail een melding te ontvangen wanneer de pagina wordt bewerkt, verwijderd of hernoemd. Als u wijzigingen in een wiki wilt bijhouden, selecteert u de knop Volgen op de wikipagina.

Deze functie heeft prioriteit gekregen op basis van dit suggestieticket. Zie onze documentatie hier voor meer informatie.

Beheer

Facturering voor uw organisatie beheren vanuit Azure DevOps

We zijn blij te kunnen aankondigen dat u nu de facturering van uw organisatie kunt beheren vanuit de Azure DevOps-portal. Beheerders hoeven facturering niet meer in te stellen via de Azure Portal. Als u de factureringsinstellingen wilt beheren, gaat u naar Uw organisatie-instellingen en selecteert u Facturering.

Hieronder ziet u een lijst met instellingen die u kunt beheren op het tabblad Facturering .

1. U kunt een Azure-abonnement kiezen dat u wilt gebruiken voor facturering.

   

2. U kunt het Azure-abonnement wijzigen dat uw organisatie voor facturering gebruikt door een ander abonnement te selecteren. Voorheen moest u de facturering verwijderen en vervolgens zorgvuldig hetzelfde niveau opnieuw kopen voor elk van uw betaalde resources (basisgebruikers, gebruikers van pakketbeheer, door MS gehoste pijplijnen, enzovoort). Dit proces was omslachtig en foutgevoelig. U kunt nu het Azure-abonnement wijzigen dat uw organisatie voor facturering gebruikt door een ander abonnement te selecteren en op Opslaan te klikken.

   

3. U hoeft niet langer naar Visual Studio Marketplace te gaan om de factureringsinstellingen te beheren. We hebben de mogelijkheid toegevoegd om te betalen voor extra gebruikers van Basic, Test Manager en Package Management (Azure Artifacts). U kunt het aantal gebruikers dat uw organisatie betaalt verhogen of verlagen via het nieuwe tabblad Facturering .

   

Volgende stappen

Notitie

Deze functies worden in de komende twee tot drie weken uitgerold.

Ga naar Azure DevOps en neem een kijkje.

Ga naar Azure DevOps

Feedback geven

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

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

Met vriendelijke groet,

Jeremy Epling