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 binnen onze portal te beheren.

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

Bekijk de functies lijst hieronder voor meer informatie.

Functies

Algemeen:

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

Azure Boards:

• Query's uitvoeren op basis van Azure Active Directory-groepen
• Deel het bord van uw team met behulp van een badge
• Vragen naar werk met betrekking tot het begin van de dag, week, maand of jaar
• Queryresultaten exporteren naar een CSV-bestand

Azure Repositories:

• Nieuwe samenvoegtypen voor het voltooien van pull-aanvragen

Azure Pipelines:

• Kubernetes-manifesttaak
• Upgrades naar Docker-taak
• installatieprogramma voor Kubectl-hulpprogramma's
• Azure Container Registry in Docker-registerserviceverbinding
• cgroup-ondersteuning voor gehoste Ubuntu-pool
• Eenmaal uitgevoerde agent
• Ondersteuning voor Visual Studio 2019 (VS2019) in Visual Studio-testtaak
• Update van gebruikersinterface van agentgroep
• Taakassistent voor het bewerken van YAML-bestanden
• Afbeeldingsupdates voor gehoste pipelines
• Verbeteringen in ServiceNow-integratie
• Ondersteuning voor Azure PowerShell Az-module
• Verbeteringen in de autorisatie van resources
• Vereenvoudigd bewaarbeleid voor build-pijplijnen
• Artefacten van de pijplijn die automatisch worden opgehaald in de release
• Updates van Cobertura-code dekkingsrapport

Berichtgeving:

• Rapporten met buildfouten en duur
• Algemene beschikbaarheid van Analytics

Wiki:

• Meldingen op wikipagina's

Bestuur:

• Facturering voor uw organisatie beheren vanuit Azure DevOps

Algemeen

Algemene beschikbaarheid van donker thema

Afgelopen oktober hebben we de openbare preview van het donkere thema uitgebracht als onderdeel van de nieuwe navigatie. Na enkele maanden in preview, 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 via Azure DevOps

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

Hieronder ziet u een lijst met instellingen die u kunt beheren via 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 gebruikt voor facturering door een ander abonnement te selecteren. Voorheen moest u facturering verwijderen en vervolgens zorgvuldig hetzelfde niveau opnieuw inkopen voor elk van uw betaalde resources (Basisgebruikers, Pakketbeheergebruikers, MS Gehoste pijplijnen, enzovoort). Dit proces was vervelend en gevoelig voor fouten. U kunt nu het Azure-abonnement wijzigen dat uw organisatie gebruikt voor facturering 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

Queries uitvoeren gebaseerd op Azure Active Directory-groepen

Dankzij de toegenomen acceptatie van Azure Active Directory en de prevalentie van het gebruik van groepen om beveiliging te beheren, zijn teams steeds vaker 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 ofNiet in groep , kunt u ook Rechtstreeks Azure Active Directory-groepen gebruiken.

Raadpleeg de documentatie voor queryoperators voor meer informatie.

Deel het teamboard met een badge

Het README-bestand van de opslagplaats is vaak het referentiepunt waar je projectteam terecht kan voor informatie over hoe je kunt bijdragen aan en gebruik kunt maken van je oplossing. U kunt nu, net als met een build- of implementatiestatus in Azure Pipelines, een badge toevoegen aan uw README voor het bord van uw team in Azure Boards. U kunt de badge zo configureren dat alleen de Wordt uitgevoerd kolommen of alle kolommen worden weergegeven, en zelfs de badge openbaar zichtbaar maken als uw project open source is.

Als uw README is gebaseerd op Markdown, kunt u de voorbeeld-Markdown kopiëren vanaf de instellingen van de statusbadge en deze in uw bestand plakken.

Werk opvragen 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 via de lens van de agenda om te rapporteren over al het werk dat vorige maand of in het eerste kwartaal van het jaar is gebeurd. U kunt nu de volgende nieuwe set @StartOf macro's samen met een datumveld gebruiken om een query 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 kunt verplaatsen op verschillende datumeenheden. 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 de datum >van statuswijziging = @StartOfYear en de datum <van statuswijziging = @StartOfYear(“+3M”). Zie de querymacro's documentatie voor meer informatie.

Queryresultaten exporteren naar een CSV-bestand

U kunt nu queryresultaten rechtstreeks exporteren naar een CSV-indelingsbestand vanaf internet.

Azure Repos

Nieuwe samenvoegtypen 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 onze meest aangevraagde functies in de Ontwikkelaarscommunity: Fast-Forward samenvoegen en Semi-Linear 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 pagina voor beleidsbeheer kunnen beheerders bepalen welke samenvoegstrategieën zijn toegestaan voor een vertakking of map met vertakkingen.

Er zijn enkele situaties waarin rebasen tijdens de voltooiing van een pull-verzoek niet mogelijk is:

• Als een beleid op de doelvertakking het gebruik van rebase-strategieën verbiedt, hebt u de toestemming "Vertakkingsbeleid overschrijven" nodig.
• Als de bronvertakking van de pull request beleidsregels heeft, kunt u deze niet opnieuw baseren. Rebasing zal de bronvertakking wijzigen zonder het goedkeuringsproces voor het beleid te doorlopen.
• Als u de extensie voor samenvoegingsconflicten hebt gebruikt om samenvoegingsconflicten op te lossen. Conflictoplossingen die worden toegepast bij een driezijdige samensmelting zijn zelden succesvol (of zelfs geldig) wanneer alle commits in een pull-verzoek één voor één opnieuw worden toegepast.

In al deze gevallen hebt u nog steeds de mogelijkheid om uw vertakking lokaal te rebasen en naar de server te pushen, of uw wijzigingen samen te voegen wanneer u de pull request voltooit.

Azure-pipelines

Kubernetes-manifest-taak

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

• Substitutie van artefacten: De implementeeractie neemt een lijst met containerafbeeldingen als invoer, die samen met hun tags of hashwaarden kunnen worden opgegeven. Dit wordt vervangen door de versie zonder sjablonen van de manifestbestanden voordat het wordt toegepast op het cluster, om ervoor te zorgen dat de juiste versie van de image wordt opgehaald door de knooppunten van het cluster.

• Manifeststabiliteit: de implementatiestatus wordt gecontroleerd op de Kubernetes-objecten die zijn geïmplementeerd om stabiliteitscontroles op te nemen terwijl de taakstatus als geslaagd/mislukt wordt gecomputeerd.

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

• Bakmanifest: 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 -baseline en -canary, zodat deze kunnen worden vergeleken tijdens een ManualIntervention taak voordat de actie promoveren/afwijzen van de taak wordt gebruikt om de versie definitief vast te stellen die behouden moet worden.

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 voor 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 om u aan te melden bij containerregisters. Traceerbaarheidsmetagegevens over bronrepository, commit en build-herkomst worden als labels toegevoegd aan de installatiekopieën die met deze taak zijn gebouwd.

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 het hulpprogramma Kubectl

Er is 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 de Kubectl-versiespecificatie.

Azure-containerregister in Docker-registerserviceverbinding

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 Ad-identiteit (Azure Active Directory). Alle taken die serviceverbindingen met containerregisters vereisen, zoals Docker@2 en KubernetesManifest@0 ondersteunen één manier om een verbinding op te geven.

Ondersteuning voor cgroup in gehoste Ubuntu-pool

Wanneer het geheugengebruik in Linux te hoog wordt, beëindigt de kernel enkele processen om de rest te beveiligen. Als het proces van de Azure Pipelines-agent is geselecteerd voor beëindiging, mislukt de pijplijnuitvoering met een foutbericht over het verlies van communicatie met de agent. In de door Microsoft gehoste Ubuntu-pool hebben we de kans verkleind dat de agent wordt beëindigd door stappen in een aangepaste cgroup uit te voeren. Hoewel uw pijplijn nog steeds kan mislukken als u het beschikbare geheugen te boven gaat, is het waarschijnlijker dat het agentproces blijft functioneren 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.

Eenmalig uitvoerende 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 u weggaat. Tot nu toe was dit niet eenvoudig, omdat u de agent moest beëindigen (wat mogelijks een fout zou kunnen veroorzaken) of het risico moest accepteren dat een agent misschien een andere taak kreeg voordat u hem kon uitschakelen. Met deze update hebben we de --once vlag toegevoegd aan de agentconfiguratie. Wanneer u de agent op deze manier configureert, accepteert deze slechts één taak en sluit het zichzelf af.

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 meest recente of Visual Studio 2019-opties in de vervolgkeuzelijst Platformversie testen.

Update voor gebruikersinterface voor agentpool

De beheerpagina voor agentgroepen 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.

Taakassistent voor het bewerken van YAML-bestanden

We blijven veel feedback ontvangen om het gemakkelijker te maken YAML-bestanden voor pijplijnen te bewerken. In de vorige updates hebben we intellisense-ondersteuning toegevoegd. Nu voegen we een taakassistent toe 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 algemene typen taakinvoer, zoals selectielijsten en serviceverbindingen. Als u de nieuwe taakassistent wilt gebruiken, selecteert u Bewerken op een YAML-pijplijn en selecteert u vervolgens de Taakassistent.

Updates voor gehoste pipeline-afbeeldingen

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

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

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

vmImage: 'macOS-latest'

• Dit afbeeldingslabel is specifiek gericht op mac OS 10.4 als u zeker wilt zijn dat uw pijplijn wordt uitgevoerd op 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 in 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.

Voor meer informatie over wat er is opgenomen in onze gehoste macOS VM-installatiekopieën en meer informatie over de hulpprogramma's die beschikbaar zijn op onze installatiekopieën, gaat u naar onze opslagplaats voor het genereren van installatiekopieën op GitHub.

Verbeteringen voor ServiceNow-integratie

Afgelopen december hebben we de integratie van ServiceNow Change Management met releasepijplijnen uitgebracht. Een belangrijke mogelijkheid voor samenwerking tussen teams die elk team in staat stelde een service van hun keuze te gebruiken en effectieve end-to-end levering te hebben. Met deze update hebben we de integratie verbeterd ter ondersteuning van alle soorten wijzigingen (normaal, standaard en noodgeval). 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 vanaf de opdrachtregel te beheren. Afgelopen december is de Az-module van Azure PowerShell beschikbaar en is deze nu de beoogde module voor het beheren van uw Azure-resources.

Voorheen bieden we geen ondersteuning voor de Azure PowerShell Az-module in onze gehoste agents. Met de nieuwe Azure PowerShell-taak versie 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 om zo snel mogelijk over te schakelen naar de Azure PowerShell-taakversie 4.* .

De Az-module heeft een compatibiliteitsmodus om u te helpen bij het gebruik van bestaande scripts terwijl u ze bijwerkt om de nieuwe syntaxis te gebruiken. Als u compatibiliteit voor de Az-module wilt inschakelen, gebruikt u de opdracht Enable-AzureRmAlias. Met aliassen kunt u de oude cmdlet-namen gebruiken met az-module. U kunt meer informatie krijgen over het migreren van de Azure RM-module naar de Azure PowerShell Az-module hier.

Zie de documentatie hiervoor meer informatie over de Azure PowerShell Az-module.

Verbeteringen in de autorisatie van middelen

We moesten beveiliging bieden voor beveiligde resources (bijvoorbeeld serviceverbindingen, variabele groepen, agentgroepen, beveiligde bestanden) wanneer ernaar wordt verwezen in een YAML-bestand. Tegelijkertijd wilden 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 is het eenvoudiger voor u om een probleem met resourceautorisatie op te lossen, zelfs als u een resource als zodanig niet hebt gemarkeerd. Wanneer een build mislukt vanwege een resourceautorisatiefout, ziet u in de nieuwe ervaring een optie om het gebruik van deze resources in de pijplijn expliciet te autoriseren en vervolgens door te gaan. Teamleden met machtigingen voor het autoriseren van resources kunnen deze actie rechtstreeks vanuit een mislukte build voltooien.

Vereenvoudigd retentiebeleid voor build-pipelines

We hebben het retentiemodel voor alle build-pijplijnen, inclusief YAML-builds, vereenvoudigd. 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 met instellingen voor pijplijnen van projectinstellingen.

Pijplijnartefacten worden automatisch opgehaald in release

Voorheen, als de build-pijplijn die aan een release was gekoppeld eerder artefacten had gepubliceerd met behulp van de taak Publish Pipeline Artifact, werden deze artefacten niet automatisch opgehaald in de release. In plaats daarvan moest u expliciet een taak Pipeline Artefact downloaden toevoegen in de release-pijplijn om de artefacten te downloaden.

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

Updates voor Cobertura-codedekkingsrapporten

Voorheen, wanneer je tests in een pipeline draaide en code-dekkingsresultaten naar Azure DevOps publiceerde, was het noodzakelijk om zowel het XML-overzicht als een HTML-rapportbestand te specificeren. Daarnaast zijn stijlen in de HTML-rapporten verwijderd voordat ze werden weergegeven op het tabblad Codedekking. Deze verwijdering van styling was noodzakelijk vanuit een beveiligingsstandpunt omdat willekeurige HTML-bestanden konden worden geüpload.

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

Berichtgeving

Rapporten van bouwmislukkingen en duur

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

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

   

2. Het duurrapport bevat de duur van het proces en de bijbehorende trends.

   

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 die gegevens op een dashboard weergeven en u helpen bij het bewaken van de voortgang van uw werk. De opgenomen widgets zijn het volgende:

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

     

   • Cyclustijd en doorlooptijd om te visualiseren hoe het werk door de ontwikkelingscyclus van uw team verloopt

     

   • Cumulatief stroomdiagram (CFD) houdt werkitems bij naarmate ze door verschillende toestanden gaan.

     

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

     

   • Testresultatentrend om testtrends te controleren, fout- en duurpatronen te detecteren voor tests via één of meerdere pijplijnen.

     

2. In het product voegen we het rapport van de meest falende tests toe om inzicht te krijgen uit de belangrijkste mislukte tests in uw pijplijn. Dit zal helpen de betrouwbaarheid van uw pijplijn te verbeteren en testschuld te verminderen.

   

We blijven ook Power BI-integratie aanbieden 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 u dat eerder hebt gedaan en hoeft u geen aanvullende stappen te volgen. Dit betekent dat we de Analytics Marketplace-extensie voor gehoste klanten zullen verwijderen.

De Azure DevOps Analytics-aanbieding 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

• Analytics-widgets

• 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 hiervoor meer informatie.

Bestuur

Facturering voor uw organisatie beheren via Azure DevOps

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

Hieronder ziet u een lijst met instellingen die u kunt beheren via 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 gebruikt voor facturering door een ander abonnement te selecteren. Voorheen moest u facturering verwijderen en vervolgens zorgvuldig hetzelfde niveau opnieuw inkopen voor elk van uw betaalde resources (Basisgebruikers, Pakketbeheergebruikers, MS Gehoste pijplijnen, enzovoort). Dit proces was vervelend en gevoelig voor fouten. U kunt nu het Azure-abonnement wijzigen dat uw organisatie gebruikt voor facturering 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

Ga naar Azure DevOps en kijk eens.

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 beantwoorden door de community op Stack Overflow.

Bedankt

Jeremy Epling