Delen via

Facturering op basis van gebruikerstoewijzing, standaardtoegangsniveau en dagelijkse facturering - Sprint 158 Update

  • Artikel

In de Sprint 158-update van Azure DevOps hebben we facturering op basis van gebruikerstoewijzingen toegevoegd. Met deze functie wordt het aantal licenties voor Basic of Basic + Test Plan gewijzigd wanneer u gebruikers toevoegt of verwijdert. Dit betekent dat u alleen betaalt voor de licenties die u gebruikt. We hebben ook een nieuwe instelling toegevoegd waarmee u kunt kiezen of u wilt dat nieuwe gebruikers die aan uw organisatie worden toegevoegd volledige basistoegang krijgen of beperkte/gratis toegang tot belanghebbenden.

Ook zijn we van maandelijkse facturering overgegaan op dagelijkse facturering. Dit betekent dat als u een gebruiker betaalde toegang geeft voor een paar weken of zelfs een paar dagen, u alleen betaalt voor de periode dat u de betaalde toegang aan de betreffende gebruiker hebt toegewezen en niet voor een volledige maand.

Bekijk de onderstaande lijst met functies voor meer informatie.

Wat is er nieuw in Azure DevOps?

Functies

Algemeen:

Azure Boards:

Azure-opslagplaats:

Azure Pipelines:

Azure Test Plans:

Rapportage:

Wiki:

Algemeen

Facturering op basis van gebruikerstoewijzing en standaardtoegangsniveau

Facturering op basis van gebruikerstoewijzing

Met deze update hebben we facturering op basis van gebruikerstoewijzingen toegevoegd. In plaats van het aantal betaalde Basic- of Basic + Test Plan-licenties te verhogen of te verlagen, is uw organisatie nu automatisch beschikbaar wanneer u gebruikers toevoegt of verwijdert of hun toegangsniveau wijzigt. Dit betekent dat u nooit betaalt voor meer licenties dan u gebruikt en dat het automatiseren van uw toewijzing op toegangsniveau veel eenvoudiger wordt. U hebt bijvoorbeeld groepsregels ingesteld om te bepalen welk toegangsniveau wordt toegewezen aan nieuwe gebruikers die automatisch lid worden van uw team. In het verleden werkten deze echter alleen als u extra licenties had waarvoor u betaalt, nog niet aan iemand was toegewezen en als u opraakt, is de groepsregel mislukt. Dit soort fouten treden niet meer op, zolang het Azure-abonnement dat u gebruikt voor facturering actief blijft.

Standaardtoegangsniveau voor nieuwe gebruikers

We hebben ook een nieuwe instelling toegevoegd waarmee u kunt kiezen of u wilt dat nieuwe gebruikers die aan uw organisatie worden toegevoegd volledige basistoegang krijgen of beperkte/gratis toegang tot belanghebbenden. In het verleden kregen nieuwe gebruikers Basic als er niet-toegewezen Basic-licenties beschikbaar waren, maar belanghebbende als dat niet het was. Alle organisaties beginnen met hun standaardtoegangsniveau ingesteld op Belanghebbende, dus er worden geen onverwachte kosten voor nieuwe gebruikers in rekening gebracht. Als uw organisatie doorgaans extra niet-toegewezen licenties heeft bewaard, zodat nieuwe gebruikers die aan projecten zijn toegevoegd volledige basistoegang hebben, moet u ervoor zorgen dat u het standaardtoegangsniveau wijzigt in Basic.

Default access level for new users.

Dagelijkse facturering

Als onderdeel van de wijziging in facturering op basis van toewijzingen, zijn we ook overgeschakeld van maandelijks naar dagelijks factureren. Als u nu een gebruiker een paar weken of zelfs een paar dagen betaalde toegang geeft, betaalt u alleen voor de tijd dat ze de betaalde toegang hebben toegewezen, in plaats van een volledige maand. Wanneer we uw organisatie veranderen van maandelijks naar dagelijks factureren, is uw volgende Azure-factuur waarschijnlijk lager dan voorheen. De volgende maand is weer normaal zodra deze een volledige maand aan samengevoegde dagelijkse kosten heeft.

Nieuwe gebruikersinterface voor het beheren van organisatie- en projectmachtigingen

Het beheer van organisatie- en projectmachtigingen heeft een nieuw uiterlijk en de prestaties zijn verbeterd. Nieuwe groepsleden worden nu weergegeven in de lijst wanneer ze worden toegevoegd zonder dat er een geforceerde paginavernieuwing is vereist. Ga naar uw organisaties Instellingen en kijk eens.

Manage organization and project permissions.

Azure Boards

Ondersteuning voor aangepaste velden in samengetelde kolommen

Samenvouwen kan nu worden uitgevoerd voor elk veld, inclusief aangepaste velden. Wanneer u een samengetelde kolom toevoegt, kunt u nog steeds een samengetelde kolom kiezen in de lijst Snel, maar als u wilt samenvouwen op numerieke velden die geen deel uitmaken van de kant-en-klare processjabloon, kunt u uw eigen kolom als volgt configureren:

  1. Klik in de achterstand op Kolomopties. Klik vervolgens in het deelvenster op Rollup-kolom toevoegen en configureer aangepaste rollup.

    Rollup on custom fields.

  2. Kies tussen de voortgangsbalk en het totaal.
  3. Selecteer een werkitemtype of een achterstandsniveau (meestal worden verschillende typen werkitems samengevoegd).
  4. Selecteer het aggregatietype. Aantal werkitems of Som. Voor Som moet u het veld selecteren dat u wilt samenvatten.
  5. Met de knop OK gaat u terug naar het deelvenster met kolomopties, waar u de volgorde van de nieuwe aangepaste kolom kunt wijzigen.

Support for custom fields in Rollup columns.

Houd er rekening mee dat u de aangepaste kolom niet kunt bewerken nadat u op OK hebt geklikt. Als u een wijziging wilt aanbrengen, verwijdert u de aangepaste kolom en voegt u desgewenst nog een kolom toe.

Nieuwe regel om velden te verbergen in een werkitemformulier op basis van voorwaarde

We hebben een nieuwe regel toegevoegd aan de overgenomen regelengine, zodat u velden in een werkitemformulier kunt verbergen. Met deze regel worden velden verborgen op basis van het groepslidmaatschap van gebruikers. Als de gebruiker bijvoorbeeld deel uitmaakt van de groep producteigenaar, kunt u een specifiek veld voor ontwikkelaars verbergen. Zie de documentatie hier voor meer informatie.

Aangepaste meldingsinstellingen voor werkitems

Het is ongelooflijk belangrijk om op de hoogte te blijven van werkitems die relevant zijn voor u of uw team. Het helpt teams samen te werken en op de hoogte te blijven van projecten en ervoor te zorgen dat alle juiste partijen betrokken zijn. Verschillende belanghebbenden hebben echter verschillende investeringsniveaus in verschillende inspanningen en we geloven dat dit moet worden weerspiegeld in uw vermogen om de status van een werkitem te volgen.

Als u eerder een werkitem wilt volgen en meldingen wilt ontvangen over wijzigingen die zijn aangebracht, ontvangt u e-mailmeldingen voor alle wijzigingen die zijn aangebracht in het werkitem. Nadat u uw feedback hebt overwogen, maken we het volgen van een werkitem flexibeler voor alle belanghebbenden. Nu ziet u een nieuwe knop Instellingen naast de knop Volgen in de rechterbovenhoek van het werkitem. Hiermee gaat u naar een pop-upvenster waarmee u de volgende opties kunt configureren.

Configure follow options.

In Notification Instellingen kunt u kiezen uit drie meldingsopties. Ten eerste kun je je volledig afmelden. Ten tweede kunt u volledig worden geabonneerd, waarbij u meldingen ontvangt voor alle wijzigingen in het werkitem. Ten slotte kunt u ervoor kiezen om een melding te ontvangen voor enkele van de belangrijkste en cruciale wijzigingen van werkitems. U kunt slechts één of alle drie de opties selecteren. Hierdoor kunnen teamleden werkitems op een hoger niveau volgen en niet worden afgeleid door elke wijziging die wordt aangebracht. Met deze functie elimineren we overbodige e-mailberichten en kunnen we u richten op de belangrijke taken die u bij de hand hebt.

Choose Notification Settings.

We zijn verheugd om een preview van het besturingselement Implementatie op het werkitemformulier vrij te geven. Met dit besturingselement worden uw werkitems gekoppeld aan een release en kunt u eenvoudig bijhouden waar uw werkitem is geïmplementeerd. Zie de documentatie hier voor meer informatie.

Link work items to deployments.

Azure-opslagplaatsen

Verificatie op basis van serviceaccounts gebruiken om verbinding te maken met AKS

Voorheen hebben we bij het configureren van Azure Pipelines vanuit het AKS Deployment Center een Azure Resource Manager-Verbinding maken ion gebruikt. Deze verbinding had toegang tot het hele cluster en niet alleen de naamruimte waarvoor de pijplijn is geconfigureerd. Met deze update gebruiken onze pijplijnen verificatie op basis van serviceaccounts om verbinding te maken met het cluster, zodat deze alleen toegang heeft tot de naamruimte die is gekoppeld aan de pijplijn.

Voorbeeld van Markdown-bestanden in pull-aanvraag naast elkaar weergeven

U kunt nu een voorbeeld bekijken van hoe een Markdown-bestand eruitziet met behulp van de nieuwe knop Voorbeeld . Daarnaast kunt u de volledige inhoud van een bestand in de diff naast elkaar zien door de knop Weergave te selecteren.

Preview Markdown files in pull request Side-by-side diff.

Verlooptijd van buildbeleid voor handmatige builds

Beleidsregels dwingen de codekwaliteits- en wijzigingsbeheerstandaarden van uw team af. Voorheen kon u verloopbeleid voor builds instellen voor geautomatiseerde builds. U kunt nu ook het verloopbeleid voor build instellen op uw handmatige builds.

Build policy expiration for manual builds.

Een beleid toevoegen om doorvoeringen te blokkeren op basis van het e-mailadres van de auteur van de doorvoering

Beheer istrators kunnen nu een pushbeleid instellen om te voorkomen dat doorvoeringen worden gepusht naar een opslagplaats waarvoor de doorvoeringsauteur-e-mail niet overeenkomt met het opgegeven patroon.

Add a policy to block commits based on the commit author email.

Deze functie heeft prioriteit gekregen op basis van een suggestie van de Ontwikkelaarscommunity om een vergelijkbare ervaring te bieden. We blijven het ticket open houden en gebruikers aanmoedigen om ons te laten weten welke andere typen pushbeleid u wilt zien.

Azure-pipelines

Mislukte fasen opnieuw proberen

Notitie

Als u deze functie wilt proberen, moet de preview-functie pijplijnen met meerdere fasen zijn ingeschakeld.

Een van de meest aangevraagde functies in pijplijnen met meerdere fasen is de mogelijkheid om een mislukte fase opnieuw uit te voeren zonder dat u vanaf het begin hoeft te beginnen. Met deze update voegen we een groot deel van deze functionaliteit toe.

U kunt nu een pijplijnfase opnieuw proberen wanneer de uitvoering mislukt. Taken die in de eerste poging zijn mislukt en taken die transitief afhankelijk zijn van die mislukte taken, worden allemaal opnieuw geprobeerd.

Dit kan u helpen tijd op verschillende manieren te besparen. Wanneer u bijvoorbeeld meerdere taken in een fase uitvoert, wilt u mogelijk dat elke fase tests uitvoert op een ander platform. Als de tests op één platform mislukken terwijl anderen slagen, kunt u tijd besparen door de doorgegeven taken niet opnieuw uit te voeren. Een andere voorbeeld: een implementatiefase is mogelijk mislukt vanwege een flaky netwerkverbinding. Als u die fase opnieuw probeert, bespaart u tijd door geen andere build te produceren.

Er zijn enkele bekende hiaten in deze functie. U kunt bijvoorbeeld geen fase opnieuw proberen die u expliciet annuleert. We werken eraan om deze hiaten in toekomstige updates te sluiten.

Verbeteringen voor goedkeuringen in YAML-pijplijnen

Notitie

U moet beschikken over pijplijnen met meerdere fasen en preview-functies voor nieuwe serviceverbindingen om deze functie uit te proberen.

We blijven YAML-pijplijnen met meerdere fasen verbeteren. Met deze update hebben we goedkeuringen voor serviceverbindingen en agentpools geconfigureerd. Voor goedkeuringen volgen we scheiding van rollen tussen infrastructuureigenaren en ontwikkelaars. Door goedkeuringen te configureren voor uw resources, zoals omgevingen, serviceverbindingen en agentgroepen, bent u ervan verzekerd dat alle pijplijnuitvoeringen die gebruikmaken van resources eerst goedkeuring vereisen.

De ervaring is vergelijkbaar met het configureren van goedkeuringen voor omgevingen. Wanneer een goedkeuring in behandeling is voor een resource waarnaar in een fase wordt verwezen, wacht de uitvoering van de pijplijn totdat de pijplijn handmatig wordt goedgekeurd.

Enhancements to approvals in YAML pipelines.

Ondersteuning voor containerstructuurtests in Azure Pipelines

Het gebruik van containers in toepassingen neemt toe en daarom is er behoefte aan robuuste tests en validaties. Azure Pipelines biedt nu ondersteuning voor Container Structure Tests. Dit framework biedt een handige en krachtige manier om de inhoud en structuur van uw containers te controleren.

U kunt de structuur van een afbeelding valideren op basis van vier categorieën tests die samen kunnen worden uitgevoerd: opdrachttests, bestaanstests van bestanden, bestandsinhoudstests en metagegevenstests. U kunt de resultaten in de pijplijn gebruiken om go/no go-beslissingen te nemen. Testgegevens zijn beschikbaar in de pijplijnuitvoering met een foutbericht om u te helpen bij het oplossen van fouten.

Voer de details van het configuratiebestand en de installatiekopieën in

Container structure testing support in Azure Pipeline.

Gegevens en samenvatting testen

Test data and summary.

Flaky bugs beheren en oplossen

In juli hebben we flaky testbeheer geïntroduceerd ter ondersteuning van de end-to-end levenscyclus met detectie, rapportage en oplossing. Om dit verder te verbeteren voegen we flaky test bug management en oplossing toe.

Tijdens het onderzoeken van de flaky test kunt u een bug maken met behulp van de bugactie die vervolgens kan worden toegewezen aan een ontwikkelaar om de hoofdoorzaak van de flaky test verder te onderzoeken. Het foutenrapport bevat informatie over de pijplijn, zoals foutbericht, stacktracering en andere informatie die aan de test is gekoppeld.

Wanneer een foutrapport is opgelost of gesloten, wordt de test automatisch als ontvlambaar gemarkeerd.

Verbeteringen in Azure Pipelines-app voor Slack en Microsoft Teams

Op YAML gebaseerde pijplijnen met meerdere fasen

Notitie

Als u deze functie wilt proberen, moet de preview-functie pijplijnen met meerdere fasen zijn ingeschakeld.

De Azure Pipelines-app voor Slack en Microsoft Teams ondersteunt nu YAML-pijplijnen met meerdere fasen voor CI en CD. Met deze uitbreiding krijgt u een melding over verschillende gebeurtenissen met betrekking tot YAML-pijplijnen.

Enhancements to Azure Pipelines app for Slack and Microsoft Teams.

Gebeurtenissen die worden ondersteund voor YAML-pijplijnen met meerdere fasen

  • Status van uitvoering gewijzigd
  • Status van uitvoeringsfase gewijzigd
  • Fase uitvoeren die wacht op goedkeuring
  • Goedkeuring van uitvoeringsfase voltooid

Events supported for multi-stage YAML pipelines.

URL-uitbreidingen opheffen en berichten

We hebben een berichtextensie toegevoegd voor de Azure Pipelines-app voor Microsoft Teams. U kunt nu zoeken naar pijplijnen en relevante details over de pijplijn delen als een kaart in het kanaal. Url-uitsplitsing helpt u discussies over pijplijnen te initiëren en zinvolle en contextuele gesprekken te voeren.

URL unfurling and messaging extensions.

Updates in gehoste afbeeldingen voor pijplijnen

We hebben verschillende door Azure Pipelines gehoste VM-installatiekopieën bijgewerkt. Hier volgen enkele belangrijke punten in deze update:

  • Go 1.13 toegevoegd aan Ubuntu 16.04, Ubuntu 18.04, VS2017 en VS2019. Go 1.12 blijft de standaardwaarde.
  • Android SDK en Build Tools 29 toegevoegd aan Ubuntu 16.04, Ubuntu 18.04, VS2017 en VS2019.
  • Az Module 2.6.0 toegevoegd aan VS2017 en VS2019.
  • Verschillende bugfixes.

Meer informatie over de nieuwste releases vindt u hier.

Notitie

We verwijderen Ruby 2.3 uit alle afbeeldingen in een toekomstige update, omdat deze op 31 maart 2019 het einde van de levensduur heeft bereikt.

Taak voor installatieprogramma van Open Policy Agent

Open Policy Agent is een open source beleidsengine voor algemeen gebruik waarmee uniforme, contextbewuste beleids afdwinging mogelijk is. We hebben de taak voor het installatieprogramma van de Open Policy Agent toegevoegd. Het is met name handig voor het afdwingen van in-pipeline-beleid met betrekking tot infrastructuur als codeproviders.

Open Policy Agent kan bijvoorbeeld Rego-beleidsbestanden en Terraform-plannen in de pijplijn evalueren.

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

Pijplijndecorators voor releasepijplijnen

Met pijplijn-decorators kunt u stappen toevoegen aan het begin en einde van elke taak. Dit verschilt van het toevoegen van stappen aan één definitie, omdat deze van toepassing is op alle pijplijnen in een organisatie.

We ondersteunen decorators voor builds en YAML-pijplijnen, waarbij klanten deze gebruiken om de stappen in hun taken centraal te beheren. We breiden nu ook de ondersteuning voor release-pijplijnen uit. U kunt extensies maken om stappen toe te voegen die gericht zijn op het nieuwe bijdragepunt en ze worden toegevoegd aan alle agenttaken in release-pijplijnen.

Azure Test Plans

Nieuwe pagina voor Test Plans

De meeste plannings-, ontwerp-, uitvoerings- en traceringsmogelijkheden zijn nu beschikbaar op de nieuwe pagina Testplannen. Daarom schakelen we het in voor alle gebruikers van testplannen, zodat ze ons feedback kunnen geven. De resterende mogelijkheden vereisen dat we pariteit kunnen bereiken met de pagina Vorige testplannen, worden in de volgende sprints ingeschakeld. Indien nodig kunnen gebruikers de pagina Testplannen uitschakelen in het menu Preview-functies. Meer informatie is hier beschikbaar.

Rapportage

Inline burndown van sprint met behulp van artikelpunten

Je Sprint Burndown kan nu burndown door Verhalen. Hiermee wordt uw feedback van de ontwikkelaarscommunity beantwoord.

Selecteer in de Sprint-hub het tabblad Analyse. Configureer vervolgens het rapport als volgt:

  1. Achterstand verhalen selecteren
  2. Selecteren om te burndown op som van verhaalpunten

Inline sprint burndown using story points.

Wiki

Korte en leesbare Wikipagina-URL's

U hoeft geen URL met meerdere regels meer te gebruiken om koppelingen naar wikipagina's te delen. We maken gebruik van de pagina-id's in de URL om parameters te verwijderen, waardoor de URL korter en gemakkelijker te lezen is.

De nieuwe structuur van URL's ziet er als volgt uit:

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

Dit is een voorbeeld van de nieuwe URL voor een azure DevOps Wiki-pagina :

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

Dit is prioriteit gegeven op basis van dit ticket voor functiesuggesties van de Ontwikkelaarscommunity.

Ondersteuning voor mermaid-diagrammen in wiki

We hebben ondersteuning toegevoegd voor het invoegen van zeemeermindiagrammen in wikipagina's. U kunt nu stroomdiagrammen, sequentiediagrammen maken, bewerken en beheren in uw ontwerpdocumenten en Gantt-grafieken toevoegen aan uw planningsdocumenten in Azure DevOps Wiki.

Mermaid diagram support in wiki.

Dit is prioriteit gegeven op basis van dit ticket voor functiesuggesties van de Ontwikkelaarscommunity. Zie onze documentatie hier voor meer informatie over Mermaid-diagrammen.

Volgende stappen

Notitie

Deze functies worden de komende twee tot drie weken uitgerold.

Ga naar Azure DevOps en kijk eens.

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.

Make a suggestion

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

Met vriendelijke groet,

Ravi Shanker