Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
In de Sprint 155-update van Azure DevOps introduceren we nieuwe Azure Boards-rapporten om het voor u gemakkelijker te maken belangrijke metrische teamgegevens bij te houden. U ziet de nieuwe rapporten onder het tabblad Analyse in de gedeelten Borden, Backlog en Sprint. Deze rapporten zijn volledig interactief en u kunt ze aanpassen aan uw behoeften.
Daarnaast kondigen we de nieuwe Azure Boards-app voor Slack aan. Met de app kunt u de activiteit van werkitems bewaken en werkitems maken vanuit uw Slack-kanaal.
Bekijk de functies lijst hieronder voor meer informatie.
Wat is er nieuw in Azure DevOps?
Features
Algemeen:
Azure Boards:
- Krijg inzicht in de status van uw team met drie nieuwe Azure Boards-rapporten
- Azure Boards-app voor Slack
- Taskboard-kolommen aanpassen
- Wisselknop om voltooide subwerkitems in de backlog weer te geven of te verbergen
- Zoeken naar borden, achterstanden, query's en sprint vanuit het snelzoekvak
- De meest recente tags die worden weergegeven bij het taggen van een werkitem
Azure Repos
- Verbeterde filteropties voor zoeken in code
- Metrische gegevens over codedekking en vertakkingsbeleid voor pull-aanvragen
- Opmerkingenmeldingen van pull-aanvragen filteren
- Servicehook voor opmerkingen bij pull-aanvragen
Azure Artifacts:
Azure Pipelines:
YAML-pijplijnen met meerdere fasen
- Goedkeuringen in YAML-pijplijnen met meerdere fasen
- Pijplijnvariabelen beheren in YAML-editor
- Nieuwe vooraf gedefinieerde variabelen in YAML-pijplijn
- Fase annuleren in een YAML-pijplijnuitvoering met meerdere fasen
- De juiste poolgegevens voor elke taak weergeven
- Werkitems koppelen met YAML-pijplijnen met meerdere fasen
- CI-triggers voor nieuwe branches
- Pipeline-cache (publieke preview)
Gehoste VM's
Kubernetes
- kustomize en kompose als Bake Opties in de KubernetesManifest-taak
- Ondersteuning voor clusterbeheerdersreferenties in HelmDeploy-taak
Test
Azure-ervaringen
- Verbeteringen in het Implementatiecentrum voor WebApp in Azure Portal
- Verbeteringen aan DevOps Project voor virtuele machine
Integrations
General
GitHub-samenwerkers uitnodigen voor Azure DevOps
U kunt nu medewerkers van GitHub uitnodigen voor Azure DevOps wanneer u bent aangemeld met uw GitHub-identiteit. U kunt andere GitHub-gebruikers zoeken en uitnodigen vanaf de startpagina van Project en op de pagina Gebruikers in de organisatie-instellingen.
Deze mogelijkheid moet worden ingeschakeld voor bestaande organisaties via een instelling onder Beleid in de organisatie-instellingen. Deze functie is echter standaard ingeschakeld voor organisaties die zijn gemaakt door een GitHub-identiteit.
Opmerking
Deze functie is niet beschikbaar voor niet-GitHub-gebruikers, zelfs niet als het beleid is ingeschakeld.
Zie de documentatie hier voor meer informatie over het uitnodigen van teamleden. Als u problemen ondervindt met het maken van verbinding met Azure DevOps met behulp van GitHub, raadpleegt u de veelgestelde vragen over het verifiëren en uitnodigen van GitHub-gebruikers.
Azure Boards
Krijg inzicht in de status van uw team met drie nieuwe Azure Boards-rapporten
U kunt niet herstellen wat u niet kunt zien. Daarom wilt u de status en gezondheid van hun werkprocessen goed in de gaten houden. Met deze rapporten maken we het eenvoudiger voor u om belangrijke metrische gegevens bij te houden met minimale inspanning in Azure Boards.
De drie nieuwe interactieve rapporten zijn: Burndown, Cumulatief stroomdiagram (CFD) en Velocity. U kunt de rapporten bekijken op het tabblad Nieuwe analyse.
Metrische gegevens zoals sprint burndown, werkstroom en teamsnelheid geven u inzicht in de voortgang van uw team en helpen bij het beantwoorden van vragen zoals:
- Hoeveel werk hebben we nog over in deze sprint? Zijn we op weg om het te voltooien?
- Welke stap van het ontwikkelingsproces duurt het langst? Kunnen we er iets aan doen?
- Hoeveel werk moeten we plannen voor de volgende sprint op basis van eerdere iteraties?
Opmerking
De grafieken die eerder in de kopteksten werden weergegeven, zijn vervangen door deze verbeterde rapporten.
De nieuwe rapporten zijn volledig interactief en u kunt ze aanpassen aan uw behoeften. U vindt de nieuwe rapporten op het tabblad Analytics in elke hub.
De burndown-grafiek is te vinden onder de Sprints hub.
De CFD- en Velocity-rapporten zijn toegankelijk via het tabblad Analyse onder Boards and Backlogs door op de relevante kaart te klikken.
Met de nieuwe rapporten hebt u meer controle en informatie over uw team. Hieronder volgen een aantal voorbeelden:
- De Sprint Burndown en de Velocity-rapporten kunnen worden ingesteld om het aantal werkitems of de som van het resterende werk te gebruiken.
- U kunt het tijdsbestek van de burndown van de sprint aanpassen zonder dat dit van invloed is op de projectdatums. Dus als uw team meestal de eerste dag van elke sprintplanning doorbrengt, kunt u de grafiek nu aanpassen om dat weer te geven.
- Het Burndown-diagram heeft nu een watermerk met weekenden.
- Met het CFD-rapport kunt u bordkolommen zoals Ontwerpen verwijderen om meer focus te krijgen op de stroom waarop de teams controle hebben.
Hier volgt een voorbeeld van het CFD-rapport met de stroom voor de afgelopen 30 dagen van de verhalenachterstand.
De Velocity-grafiek kan nu worden bijgehouden voor alle achterstandsniveaus. U kunt nu bijvoorbeeld zowel Functies als Epics toevoegen, terwijl de vorige grafiek voorheen alleen Vereisten ondersteunde. Hier volgt een voorbeeld van een snelheidsrapport voor de laatste 6 iteraties van de achterstallige functies.
Azure Boards-app voor Slack
We zijn blij om de nieuwe Azure Boards-app voor Slack aan te kondigen. Met deze app kunt u de activiteit van werkitems bewaken en werkitems maken vanuit uw Slack-kanaal.
Met de app kunt u gebeurtenisabonnementen instellen en beheren, waaronder het maken en bijwerken van werkitems, en meldingen ontvangen voor deze gebeurtenissen in uw Slack-kanaal. De gesprekken in het Slack-kanaal kunnen worden gebruikt om werkitems te maken. U ontvangt ook persoonlijke meldingen wanneer werkitems aan u zijn toegewezen. Daarnaast kunt u met voorbeelden voor URL's voor werkitems discussies starten.
Klik hier om de Azure Boards-app te installeren.
Taskboard-kolommen aanpassen
We zijn verheugd om aan te kondigen dat we een optie hebben toegevoegd waarmee u de kolommen op het Taskboard kunt aanpassen. U kunt nu de kolommen toevoegen, verwijderen, de naam ervan wijzigen en de volgorde ervan wijzigen.
Als u de kolommen op het Taskboard wilt configureren, gaat u naar Kolomopties.
Deze functie heeft prioriteit gekregen op basis van een suggestie van de ontwikkelaarscommunity.
Omschakelen om voltooide onderliggende werkitems in de backlog weer te geven of te verbergen
Vaak wilt u bij het verfijnen van de achterstand alleen items zien die niet zijn voltooid. Nu hebt u de mogelijkheid om voltooide onderliggende items weer te geven of te verbergen in de backlog.
Als de wisselknop is ingeschakeld, ziet u alle onderliggende items in een voltooide status. Wanneer de schakelaar is uitgeschakeld, worden alle onderliggende items met een voltooide status verborgen in de backlog.
Zoeken naar borden, achterstanden, zoekopdrachten en sprints via het snelle zoekvak
U kunt nu eenvoudig toegang krijgen tot onlangs bezochte borden, achterstanden, query's en sprints vanuit het zoekvak door het zoekvak te activeren in Azure Boards.
Daarnaast kunt u zoeken naar de borden, achterstanden, query's en sprints in uw project door de bordnaam in het zoekvak te typen. Nu zijn de borden die het belangrijkst voor je zijn, binnen handbereik met één klik.
Meest recente tags weergegeven bij het taggen van een werkitem
Wanneer u een werkitem tagt, wordt met de optie voor automatisch aanvullen nu maximaal vijf van de laatst gebruikte tags weergegeven. Hierdoor kunt u gemakkelijker de juiste gegevens toevoegen aan uw werkitems.
Azure Repos
Verbeterde zoekfilteropties voor code
Eerder ondersteunde codezoekopdrachten 39 codezoekfilters, zoals opmerking: en def:. Gegevens stelden voor dat er veel filters niet werden gebruikt, daarom verwijderen we een paar filters en voegen we anderen samen. Met deze update hebben we het aantal filters teruggebracht tot 19. Dit helpt bij het efficiënter maken van zoekopdrachten voor code en het verminderen van overbodige elementen in de interface.
Bijvoorbeeld, nu wordt func: gemapt naar methode:. Als u bijvoorbeeld zoekt naar func:AccountAdmin, worden de resultaten gemapt naar methode:AccountAdmin. Op dezelfde manier worden macrodef: en macroref toegewezen aan macro:. Aan de andere kant zijn filters zoals union: en org: afgeschaft vanwege gebrek aan gebruik.
Metrische gegevens over codedekking en vertakkingsbeleid voor pull-aanvragen
U kunt nu metrische gegevens over de codedekking bekijken voor wijzigingen in de pull-aanvraagweergave (PR). Dit zorgt ervoor dat u uw wijzigingen adequaat hebt getest via geautomatiseerde tests. De dekkingsstatus wordt weergegeven als een reactie in het overzicht van de pull request. U kunt details van dekkingsinformatie weergeven voor elke coderegel die is gewijzigd in de diff-weergave.
Daarnaast kunnen eigenaren van opslagplaatsen nu beleidsregels voor codedekking instellen en voorkomen dat grote, niet-geteste wijzigingen worden samengevoegd in een vertakking. Gewenste dekkingsdrempels kunnen worden gedefinieerd in een azurepipelines-coverage.yml instellingenbestand dat is ingecheckt in de hoofdmap van de opslagplaats, en het dekkingsbeleid kan worden geconfigureerd met de bestaande optie een vertakkingsbeleid configureren voor aanvullende services in Azure Repos.
Filter commentaarmeldingen van pull-verzoeken
Opmerkingen in pull-aanvragen kunnen vaak veel ruis genereren vanwege meldingen. We hebben een aangepast abonnement toegevoegd waarmee u kunt filteren op welke opmerkingenmeldingen u zich abonneert door te selecteren op leeftijd van opmerkingen, commentator, verwijderde opmerking, genoemde gebruikers, pull-aanvraagauteur, doelbranch en threaddeelnemers. U kunt deze meldingsabonnementen maken door op het gebruikerspictogram in de rechterbovenhoek te klikken en naar gebruikersinstellingen te navigeren.
Service Hooks voor commentaar bij pull requests
U kunt nu servicehook maken voor opmerkingen in een pull-aanvraag op basis van opslagplaats en doelbranch.
Azure Artifacts
Uw pakketten openbaar delen via openbare feeds (preview)
U kunt nu uw pakketten maken en opslaan in openbare feeds. Pakketten die zijn opgeslagen in openbare feeds zijn beschikbaar voor iedereen op internet zonder verificatie, ongeacht of ze zich in uw organisatie bevinden of zelfs zijn aangemeld bij een Azure DevOps-organisatie. Lees meer over openbare feeds in onze feeddocumentatie of ga meteen naar onze zelfstudie voor het delen van pakketten.
Azure-pipelines
kustomize en kompose als bakopties in de KubernetesManifest-taak
met kustomize (onderdeel van Kubernetes sig-cli) kunt u onbewerkte, sjabloonvrije YAML-bestanden aanpassen voor meerdere doeleinden en de oorspronkelijke YAML ongewijzigd laten. Een optie voor kustomize is toegevoegd onder bake-actie van kubernetesManifest-taak , zodat elke map met kustomization.yaml-bestanden kan worden gebruikt voor het genereren van de manifestbestanden die worden gebruikt in de implementatieactie van de KubernetesManifest-taak.
steps:
- task: KubernetesManifest@0
name: bake
displayName: Bake K8s manifests from Helm chart
inputs:
action: bake
renderType: kustomize
kustomizationPath: folderContainingKustomizationFile
- task: KubernetesManifest@0
displayName: Deploy K8s manifests
inputs:
kubernetesServiceConnection: k8sSC1
manifests: $(bake.manifestsBundle)
kompose transformeert een Docker Compose-bestanden in een Kubernetes-resource.
steps:
- task: KubernetesManifest@0
name: bake
displayName: Bake K8s manifests from Helm chart
inputs:
action: bake
renderType: kompose
dockerComposeFile: docker-compose.yaml
- task: KubernetesManifest@0
displayName: Deploy K8s manifests
inputs:
kubernetesServiceConnection: k8sSC1
manifests: $(bake.manifestsBundle)
Ondersteuning voor clusteradministratorreferenties in HelmDeploy-taak
Voorheen gebruikte de HelmDeploy-taak de referenties van de clustergebruiker voor implementaties. Dit resulteerde in interactieve aanmeldingsprompts en mislukte pijplijnen voor een op Azure Active Directory gebaseerd RBAC-cluster. Om dit probleem op te lossen, hebben we een selectievakje toegevoegd waarmee u referenties van de clusterbeheerder kunt gebruiken in plaats van referenties van een clustergebruiker.
Pijplijnvariabelen beheren in de YAML-editor
We hebben de ervaring bijgewerkt voor het beheren van pijplijnvariabelen in de YAML-editor. U hoeft niet langer naar de klassieke editor te gaan om variabelen toe te voegen of bij te werken in uw YAML-pijplijnen.
Nieuwe vooraf gedefinieerde variabelen in de YAML-pijplijn
Variabelen zijn een handige manier om belangrijke stukjes gegevens in verschillende delen van uw pijplijn te introduceren. Met deze update hebben we enkele vooraf gedefinieerde variabelen toegevoegd aan een implementatietaak. Deze variabelen worden automatisch ingesteld door het systeem, gericht op de specifieke implementatieopdracht en zijn in alleen-lezenmodus.
- Environment.Id : de id van de omgeving.
- Environment.Name: de naam van de omgeving waarop de implementatietaak is gericht.
- Environment.ResourceId: de id van de resource in de omgeving waarop de implementatietaak is gericht.
- Environment.ResourceName: de naam van de resource in de omgeving waarop de implementatietaak is gericht.
Werkitems koppelen met YAML-pijplijnen met meerdere fasen
Op dit moment kunt u werkitems automatisch koppelen aan klassieke builds. Dit was echter niet mogelijk met YAML-pijplijnen. Met deze update hebben we deze kloof opgelost. Wanneer u een pijplijn uitvoert met behulp van code uit een opgegeven vertakking, koppelt Azure Pipelines de uitvoering automatisch aan alle werkitems (die worden afgeleid door de doorvoeringen in die code). Wanneer u het werkitem opent, ziet u de uitvoeringen waarin de code voor dat werkitem is gebouwd. Als u dit wilt configureren, gebruikt u het instellingenpaneel van een pijplijn.
Fase annuleren in de uitvoering van een YAML-pijplijn met meerdere fasen
Wanneer u een YAML-pijplijn met meerdere fasen uitvoert, kunt u de uitvoering van een fase annuleren terwijl deze wordt uitgevoerd. Dit is handig als u weet dat de stap gaat mislukken of als u een ander proces hebt dat u wilt uitvoeren. Deze functie is ook een vereiste om in de toekomst ondersteuning te bieden voor het opnieuw proberen van een mislukte fase.
Goedkeuringen in YAML-pijplijnen met meerdere fasen
We blijven YAML-pijplijnen met meerdere fasen verbeteren. Nu kunt u handmatige goedkeuringen toevoegen aan deze pijplijnen. Eigenaren van infrastructuur kunnen hun omgevingen beschermen en handmatige goedkeuringen zoeken voordat een fase in een pijplijn naar hen wordt geïmplementeerd. Met volledige scheiding van rollen tussen eigenaren van infrastructuur (omgeving) en toepassing (pijplijn), zorgt u ervoor dat u zich handmatig afmeldt voor implementatie in een bepaalde pijplijn en centrale controle krijgt bij het toepassen van dezelfde controles op alle implementaties in de omgeving.
De uitrol van de pijplijn naar dev wordt bij de start van de fase gestopt voor goedkeuring.
Updates voor gehoste pijplijn-afbeeldingen
We hebben updates uitgevoerd voor verschillende door Azure Pipelines gehoste VM-installatiekopieën. Meer informatie over de nieuwste releases vindt u hier. De volgende wijzigingen zijn toegevoegd als onderdeel van deze update:
Voor VS2017 en VS2019:
- Azul Java 7 toegevoegd
- Vastgemaakte Docker-installatiekopieën in cache die overeenkomen met de kernelversie van de host
- Az PowerShell-module v2.3.2 toegevoegd
- Mercurial vastgezet op v5.0.0
- Python bijgewerkt naar versies 2.7.16, 3.4.4, 3.5.4, 3.6.8, 3.7.4
- Portable Class Library toegevoegd (alleen VS 2019)
- Standaardpaden en omgevingsvariabelen van Rust gewijzigd
Voor Ubuntu 16.04:
- Helm bijgewerkt om altijd de nieuwste versie te downloaden (niet langer vastgezet op v2.14.0)
- Verschillende populaire Docker-containers toegevoegd
- Python bijgewerkt naar versies 2.7.16, 3.4.10, 3.5.7, 3.6.9, 3.7.4
- Standaardpaden en omgevingsvariabelen van Rust gewijzigd
Voor alle afbeeldingen is een
ImageVersionomgevingsvariabele toegevoegd voor de versie van de afbeelding.
Voor een volledige lijst met hulpprogramma's die beschikbaar zijn voor een bepaalde afbeelding, ga naar Instellingen > Agent-pools > Details.
Verbeteringen aan DevOps Project voor virtuele machines
In deze update hebben we de werkstroom van de virtuele Machine (VM) van DevOps Projects uitgebreid met de VM's die niet voldoen aan de quotumbeperking per locatie. Voorheen moest u de virtuele machine op naam en aanbieding kiezen. U hebt nu een weergave op aanvraag met meer informatie over de VM-aanbiedingen, zoals kosten/maand, RAM, gegevensschijven, enzovoort. Hierdoor kunt u gemakkelijker de virtuele machine selecteren die u nodig hebt.
Eén gehoste pool
In de laatste sprint hebben we gecommuniceerd dat we een nieuwe gehoste pool met de naam Azure Pipelines implementeren om alle andere gehoste pools te vervangen: gehoste, gehoste VS2017, gehoste Ubuntu 1604, gehoste Windows 2019 met VS2019, gehoste macOS en gehoste macOS High Sierra. Deze wijziging wordt geïmplementeerd met deze release.
Het hebben van meerdere gehoste pools kan soms verwarrend zijn. U krijgt geen nauwkeurig beeld van waar paralleliteit wordt gebruikt. Als u bijvoorbeeld een gelijktijdigheid van 10 parallelle taken hebt, ziet u 10 virtuele agents in elk van de gehoste pools, wat niet nauwkeurig is. Wanneer uw taak wacht op een specifieke gehoste pool (bijvoorbeeld Gehoste VS2017) met alle niet-actieve agents, kunt u denken dat de Azure Pipelines-service wordt verbroken zonder te beseffen dat de gelijktijdigheid mogelijk wordt gebruikt in andere gehoste pools (bijvoorbeeld Gehoste Ubuntu 1604).
Met deze wijziging ziet u één gehoste pool die u een nauwkeurig beeld geeft van het aantal taken dat in die pool wordt uitgevoerd. We zijn van plan deze wijziging uit te rollen in de volgende sprints. U hoeft geen wijzigingen aan te brengen in uw pijplijnen, omdat we opdrachten van de oude hostingpools automatisch omleiden naar het juiste virtuele machine-beeld in de nieuwe gecombineerde pool.
Juiste poolgegevens weergeven voor elke taak
Voorheen, toen u een matrix gebruikte om taken of een variabele uit te breiden om een pool te identificeren, hadden we problemen met het weergeven van de juiste poolgegevens op de logboekpagina's. Met deze update hebben we de problemen opgelost waardoor onjuiste poolgegevens voor bepaalde taken werden weergegeven.
In-product ondersteuning voor het beheer van flaky tests
Flaky tests kunnen de productiviteit van ontwikkelaars beïnvloeden, omdat testfouten mogelijk niet te maken hebben met de wijzigingen die worden getest. Ze kunnen ook van invloed zijn op de kwaliteit van verzonden code. Daarom hebben we in-product ondersteuning toegevoegd voor het beheer van onbetrouwbare tests. Deze functionaliteit ondersteunt de end-to-end levenscyclus met detectie, rapportage en oplossing. Flaky testbeheer ondersteunt systeem- en aangepaste detectie.
Systeemdetectie is beschikbaar via de mogelijkheid voor opnieuw uitvoeren van VSTest-taken. Een flaky test is een test die verschillende resultaten biedt, zoals geslaagd of mislukt, zelfs als er geen wijzigingen in de broncode of uitvoeringsomgeving zijn. Alle verdere uitvoeringen van de test voor dezelfde tak worden ook gemarkeerd als flaky totdat deze is opgelost en de markering verwijderd is. U kunt ook uw aangepaste detectiemechanisme aansluiten met behulp van onze API's. Zodra een test als flaky is geïdentificeerd, kunt u de details bekijken in de in-context rapportage in de pijplijn. Vervolgens kunt u bepalen of de flaky tests van invloed zijn op uw pijplijnfout. Standaard is informatie over onbetrouwbare tests beschikbaar als aanvullende metagegevens.
Hier volgt een voorbeeld van een rapport met de testsamenvatting.
Raadpleeg de documentatie hier voor meer details over het beheer van flaky tests.
Verbeteringen in het Implementatiecentrum voor WebApp in Azure Portal
We hebben het Implementatiecentrum voor WebApp in Azure Portal verbeterd met ondersteuning voor pijplijnen met meerdere artefacten. Als er nu een niet-primair artefact van Azure Pipelines is geïmplementeerd in de web-app, krijgt u relevante informatie uit Azure Portal. U hebt ook een dieptekoppeling naar de geïmplementeerde opslagplaats om rechtstreeks vanuit Azure Portal naar de opslagplaats te navigeren. De repository kan worden gehost in Azure Repos of in GitHub.
CI-triggers voor nieuwe branches
Het is een lang verwachte aanvraag om CI-builds niet te activeren wanneer een nieuwe tak wordt gemaakt, indien die tak geen wijzigingen bevat. Bekijk de volgende voorbeelden:
- U gebruikt de webinterface om een nieuwe vertakking te maken op basis van een bestaande vertakking. Hiermee wordt onmiddellijk een nieuwe CI-build geactiveerd als uw vertakkingsfilter overeenkomt met de naam van de nieuwe vertakking. Dit is ongewenst omdat de inhoud van de nieuwe vertakking hetzelfde is in vergelijking met de bestaande vertakking.
- U hebt een opslagplaats met twee mappen: app en documenten. U stelt een padfilter in voor CI zodat deze overeenkomt met 'app'. Met andere woorden, u wilt geen nieuwe build maken als een wijziging naar documenten is gepusht. U maakt een nieuwe vertakking lokaal, breng enkele wijzigingen aan in documenten en push die vertakking vervolgens naar de server. Vroeger lieten we regelmatig een nieuwe CI-build draaien. Dit is ongewenst omdat u expliciet hebt gevraagd om niet te zoeken naar wijzigingen in de map docs. Vanwege de manier waarop we een nieuwe vertakkingsgebeurtenis hebben verwerkt, lijkt het echter alsof er ook een wijziging in de app-map is aangebracht.
We hebben nu een betere manier om CI te verwerken voor nieuwe vertakkingen om deze problemen op te lossen. Wanneer u een nieuwe vertakking publiceert, zoeken we expliciet naar nieuwe commits in die vertakking en controleren we of deze overeenkomen met de padenfilters.
Terraform-integratie met Azure Pipelines
Terraform is een opensource-hulpprogramma voor het veilig en efficiënt ontwikkelen, wijzigen en versiebeheer van infrastructuur. Terraform codificeert API's in declaratieve configuratiebestanden, zodat u infrastructuur kunt definiëren en inrichten met behulp van een configuratietaal op hoog niveau. U kunt de Terraform-extensie gebruiken om resources te maken voor alle belangrijke infrastructuurproviders: Azure, Amazon Web Services (AWS) en Google Cloud Platform (GCP).
Zie de documentatie hier voor meer informatie over de Terraform-extensie.
Integratie met Google Analytics
Met het Framework voor Google Analytics-experimenten kunt u bijna elke wijziging of variatie op een website of app testen om de impact ervan op een specifieke doelstelling te meten. U kunt bijvoorbeeld activiteiten hebben die uw gebruikers moeten voltooien (bijvoorbeeld een aankoop doen, registreren voor een nieuwsbrief) en/of metrische gegevens die u wilt verbeteren (bijvoorbeeld omzet, sessieduur, bounce rate). Met deze activiteiten kunt u wijzigingen identificeren die de implementatie waard zijn op basis van de directe impact die ze hebben op de prestaties van uw functie.
Met de extensie voor Google Analytics-experimenten voor Azure DevOps worden experimentele stappen toegevoegd aan de build- en release-pijplijnen, zodat u de experimenten continu kunt herhalen, leren en implementeren door de experimenten continu te beheren en tegelijkertijd alle DevOps-voordelen van Azure Pipelines te verkrijgen.
U kunt de extensie Google Analytics-experimenten downloaden via Marketplace.
Pijplijncache (openbare bètaversie)
Met pijplijncaching kunt u de resultaten van een langlopende bewerking opslaan, zoals een pakketherstel of een afhankelijkheidscompilatie, en deze terugzetten tijdens de volgende uitvoering van een pijplijn. Dit kan leiden tot snellere builds.
Zie het blogbericht met de volledige aankondiging hier voor meer informatie.
Variabelengroep en variabele beheeropdrachten voor pijplijnen
Het kan lastig zijn om op YAML gebaseerde pijplijnen van het ene project naar het andere te overzetten, omdat u de pijplijnvariabelen en variabelegroepen handmatig moet instellen. Met de opdrachten voor variabelegroepen en variabelebeheer kunt u nu het scripten van het instellen en beheren van variabelen en variabelegroepen uitvoeren, die op hun beurt onder versiebeheer kunnen vallen, zodat u eenvoudig de instructies kunt delen om pijplijnen van het ene project naar het andere te verplaatsen en in te stellen.
Pijplijn uitvoeren voor een PR-branch
Bij het maken van een pull request kan het een uitdaging zijn om te valideren of de wijzigingen de pijplijnrun op de doelbranch kunnen doen falen. Met de mogelijkheid om een pijplijnuitvoering te activeren of een build in de wachtrij te plaatsen voor een PR-vertakking, kunt u nu de wijzigingen die worden doorgevoerd valideren en visualiseren door deze uit te voeren op de doelpijplijn. Raadpleeg de opdrachtdocumentatie az pipelines run en az pipelines build queue voor meer informatie.
De eerste pijplijnuitvoering overslaan
Wanneer u pijplijnen maakt, wilt u soms een YAML-bestand maken en doorvoeren en de pijplijnuitvoering niet activeren, omdat dit kan leiden tot een defecte uitvoering vanwege verschillende redenen: de infrastructuur is niet gereed of moet variabele/variabele groepen maken en bijwerken, enzovoort. Met Azure DevOps CLI kunt u nu de eerste geautomatiseerde pijplijnuitvoering overslaan bij het maken van een pijplijn door de parameter --skip-first-run op te slaan. Raadpleeg de opdrachtdocumentatie az pipeline create voor meer informatie.
Verbetering van service-eindpuntcommando
CLI-opdrachten voor service-eindpunten ondersteunen alleen het opzetten en beheren van azure rm- en github-service-eindpunten. Met deze release kunt u echter met service-eindpuntopdrachten elk service-eindpunt maken door de configuratie via bestand op te geven en geoptimaliseerde opdrachten te bieden: az devops service-endpoint github en az devops service-endpoint azurerm, die eersteklas ondersteuning bieden voor het maken van service-eindpunten van deze typen. Raadpleeg de opdrachtdocumentatie voor meer informatie.
Volgende stappen
Opmerking
Deze functies worden de komende twee tot drie weken uitgerold.
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
Sam Guckenheimer