Nieuwe burndownwidget voor sprints en verbeterde beveiliging van pijplijnen - Sprint 160 Update
In de Sprint 160-update van Azure DevOps hebben we een nieuwe burndownwidget voor sprint toegevoegd die ondersteuning biedt voor het afbranden op verhaalpunten, het aantal taken en het optellen van aangepaste velden. Daarnaast is de beveiliging van pijplijnen verbeterd door het bereik van toegangstoken te beperken.
Bekijk de onderstaande lijst met functies voor meer informatie.
Wat is er nieuw in Azure DevOps?
Functies
Azure-opslagplaats:
Azure Pipelines:
- Gebruikerservaring met pijplijnen voor meerdere fasen
- Canary-implementatiestrategie organiseren in een omgeving voor Kubernetes
- Goedkeuringsbeleidsregels voor YAML-pijplijnen
- ACR als een eersteklas pijplijnresource
- Metagegevens van pijplijnresources als vooraf ingestelde variabelen
- Traceerbaarheid voor pijplijnen en ACR-resources
- Vereenvoudigde resourceverificatie in YAML-pijplijnen
- Beveiliging van pijplijnen verbeteren door het bereik van toegangstokens te beperken
- Artefactcontrole evalueren
- Ondersteuning voor Markdown in geautomatiseerde testfoutberichten
- Problemen vaststellen met Cron-schema's in YAML
- Updates voor de arm-sjabloonimplementatietaak
- Beveiliging op projectniveau voor serviceverbindingen
- Ubuntu 18.04-pool
- Op de Service Mesh-interface gebaseerde canary-implementaties in KubernetesManifest-taak
- ReviewApp in omgeving
Azure Artifacts:
- Bijgewerkte ervaring voor Verbinding maken met feed
- Openbare feeds zijn nu algemeen beschikbaar met upstreamondersteuning
- Feeds met projectbereik maken vanuit de portal
Rapportage:
Wiki:
Azure-opslagplaatsen
Beleidsbeheer in meerdere opslagplaatsvertakkingen
Vertakkingsbeleid is een van de krachtige functies van Azure-opslagplaatsen waarmee u belangrijke vertakkingen kunt beveiligen. Hoewel de mogelijkheid om beleidsregels op projectniveau in te stellen in de REST API bestaat, is er geen gebruikersinterface voor. Beheerders kunnen nu beleidsregels instellen voor een specifieke vertakking of de standaardbranch voor alle opslagplaatsen in hun project. Een beheerder kan bijvoorbeeld twee minimale revisoren vereisen voor alle pull-aanvragen die zijn gedaan in elke hoofdbranch in elke opslagplaats in hun project. U vindt de functie Vertakkingsbeveiliging toevoegen in de projectinstellingen voor opslagplaatsen.
Azure-pipelines
Gebruikerservaring met pijplijnen voor meerdere fasen
We hebben gewerkt aan een bijgewerkte gebruikerservaring om uw pijplijnen te beheren. Deze updates maken de pijplijnen modern en consistent met de richting van Azure DevOps. Bovendien brengen deze updates klassieke build-pijplijnen en YAML-pijplijnen met meerdere fasen samen in één ervaring. De volgende mogelijkheden zijn bijvoorbeeld opgenomen in de nieuwe ervaring; meerdere fasen weergeven en beheren, pijplijnuitvoeringen goedkeuren, de mogelijkheid om helemaal terug in logboeken te schuiven terwijl er nog steeds een pijplijn wordt uitgevoerd en de status per vertakking van een pijplijn.
Bedankt voor iedereen die de nieuwe ervaring heeft geprobeerd. Als u het nog niet hebt geprobeerd, schakelt u pijplijnen met meerdere fasen in de preview-functies in. Zie de documentatie hier voor meer informatie over pijplijnen met meerdere fasen.
Dankzij uw feedback hebben we het volgende in de laatste twee updates behandeld.
- Vindbaarheid van de mappenweergave.
- Jumpiness in de logboekweergave.
- U kunt logboeken van vorige en huidige taken gemakkelijk weergeven, zelfs wanneer een uitvoering wordt uitgevoerd.
- Maak het gemakkelijker om tussen taken te navigeren bij het controleren van logboeken.
Notitie
In de volgende update zijn we van plan deze functie standaard in te schakelen voor iedereen. U hebt nog steeds de mogelijkheid om u af te wijzen voor de preview. Een paar weken daarna wordt de functie algemeen beschikbaar gesteld.
Canary-implementatiestrategie organiseren in een omgeving voor Kubernetes
Een van de belangrijkste voordelen van continue levering van toepassingsupdates is de mogelijkheid om snel updates naar productie te pushen voor specifieke microservices. Dit biedt u de mogelijkheid om snel te reageren op wijzigingen in bedrijfsvereisten. De omgeving is geïntroduceerd als een eersteklas concept voor het indelen van implementatiestrategieën en het vergemakkelijken van uitvaltijdsreleases. Eerder hebben we de runOnce-strategie ondersteund die de stappen eenmaal sequentieel heeft uitgevoerd. Met ondersteuning voor canary-strategie in pijplijnen met meerdere fasen kunt u nu het risico verminderen door de wijziging langzaam uit te rollen in een kleine subset. Naarmate u meer vertrouwen krijgt in de nieuwe versie, kunt u deze implementeren naar meer servers in uw infrastructuur en meer gebruikers naar de versie routeren.
jobs:
- deployment:
environment: musicCarnivalProd
pool:
name: musicCarnivalProdPool
strategy:
canary:
increments: [10,20]
preDeploy:
steps:
- script: initialize, cleanup....
deploy:
steps:
- script: echo deploy updates...
- task: KubernetesManifest@0
inputs:
action: $(strategy.action)
namespace: 'default'
strategy: $(strategy.name)
percentage: $(strategy.increment)
manifests: 'manifest.yml'
postRouteTaffic:
pool: server
steps:
- script: echo monitor application health...
on:
failure:
steps:
- script: echo clean-up, rollback...
success:
steps:
- script: echo checks passed, notify...
De canary-strategie voor Kuberenetes implementeert eerst de wijzigingen met 10% pods, gevolgd door 20% tijdens het bewaken van de status tijdens postRouteTraffic. Als alles goed gaat, zal het promoveren tot 100%.
Goedkeuringsbeleidsregels voor YAML-pijplijnen
In YAML-pijplijnen volgen we een door de resource-eigenaar beheerde goedkeuringsconfiguratie. Resource-eigenaren configureren goedkeuringen voor de resource en alle pijplijnen die gebruikmaken van de resourcepauze voor goedkeuringen voordat de fase wordt gestart die de resource verbruikt. Het is gebruikelijk dat eigenaren van SOX-toepassingen de aanvrager van de implementatie beperken tot het goedkeuren van hun eigen implementaties.
U kunt nu geavanceerde goedkeuringsopties gebruiken om goedkeuringsbeleid te configureren, zoals aanvrager moet niet goedkeuren, goedkeuring vereisen van een subset van gebruikers en time-out voor goedkeuring.
ACR als een eersteklas pijplijnresource
Als u een containerinstallatiekopieën wilt gebruiken die is gepubliceerd naar ACR (Azure Container Registry) als onderdeel van uw pijplijn en uw pijplijn moet activeren wanneer een nieuwe installatiekopieën zijn gepubliceerd, kunt u de ACR-containerresource gebruiken.
resources:
containers:
- container: MyACR #container resource alias
type: ACR
azureSubscription: RMPM #ARM service connection
resourceGroup: contosoRG
registry: contosodemo
repository: alphaworkz
trigger:
tags:
include:
- production
Bovendien kunnen metagegevens van ACR-installatiekopieën worden geopend met behulp van vooraf gedefinieerde variabelen. De volgende lijst bevat de ACR-variabelen die beschikbaar zijn voor het definiëren van een ACR-containerresource in uw pijplijn.
resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location
Metagegevens van pijplijnresources als vooraf ingestelde variabelen
We hebben vooraf gedefinieerde variabelen toegevoegd voor YAML-pijplijnbronnen in de pijplijn. Hier volgt de lijst met de beschikbare pijplijnresourcevariabelen.
resources.pipeline.<Alias>.projectName
resources.pipeline.<Alias>.projectID
resources.pipeline.<Alias>.pipelineName
resources.pipeline.<Alias>.pipelineID
resources.pipeline.<Alias>.runName
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID
Traceerbaarheid voor pijplijnen en ACR-resources
We zorgen voor volledige E2E-tracering wanneer pijplijnen en ACR-containerbronnen worden gebruikt in een pijplijn. Voor elke resource die door uw YAML-pijplijn wordt gebruikt, kunt u teruggaan naar de doorvoeringen, werkitems en artefacten.
In de overzichtsweergave van de pijplijnuitvoering ziet u:
De resourceversie die de uitvoering heeft geactiveerd. Nu kan uw pijplijn worden geactiveerd na voltooiing van een andere Azure-pijplijnuitvoering of wanneer een containerinstallatiekopieën naar ACR worden gepusht.
De doorvoeringen die door de pijplijn worden gebruikt. U kunt ook de uitsplitsing van de doorvoeringen vinden voor elke resource die door de pijplijn wordt gebruikt.
De werkitems die zijn gekoppeld aan elke resource die door de pijplijn wordt gebruikt.
De artefacten die beschikbaar zijn voor gebruik door de uitvoering.
In de weergave implementaties van de omgeving ziet u de doorvoeringen en werkitems voor elke resource die in de omgeving is geïmplementeerd.
Vereenvoudigde resourceverificatie in YAML-pijplijnen
Een resource wordt gebruikt door een pijplijn die zich buiten de pijplijn bevindt. Resources moeten worden geautoriseerd voordat ze kunnen worden gebruikt. Voorheen is het bij het gebruik van niet-geautoriseerde resources in een YAML-pijplijn mislukt met een resourceautorisatiefout. U moest de resources autoriseren vanaf de overzichtspagina van de mislukte uitvoering. Bovendien is de pijplijn mislukt als er een variabele wordt gebruikt die verwijst naar een niet-geautoriseerde resource.
We maken het nu eenvoudiger om resourceautorisaties te beheren. In plaats van de uitvoering te mislukken, wacht de uitvoering op machtigingen voor de resources aan het begin van de fase waarin de resource wordt gebruikt. Een resource-eigenaar kan de pijplijn bekijken en de resource autoriseren vanaf de pagina Beveiliging.
Beveiliging van pijplijnen verbeteren door het bereik van toegangstokens te beperken
Elke taak die wordt uitgevoerd in Azure Pipelines krijgt een toegangstoken. Het toegangstoken wordt gebruikt door de taken en door uw scripts om terug te bellen naar Azure DevOps. We gebruiken bijvoorbeeld het toegangstoken om broncode op te halen, logboeken te uploaden, resultaten, artefacten te testen of OM REST-aanroepen naar Azure DevOps uit te voeren. Er wordt een nieuw toegangstoken gegenereerd voor elke taak en het verloopt zodra de taak is voltooid. Met deze update hebben we de volgende verbeteringen toegevoegd.
Voorkomen dat het token toegang heeft tot resources buiten een teamproject
Tot nu toe was het standaardbereik van alle pijplijnen de teamprojectverzameling. U kunt het bereik wijzigen in het teamproject in klassieke build-pijplijnen. U hebt dat besturingselement echter niet voor klassieke release- of YAML-pijplijnen. Met deze update introduceren we een organisatie-instelling om elke taak af te dwingen om een token met projectbereik op te halen, ongeacht wat er in de pijplijn is geconfigureerd. We hebben ook de instelling toegevoegd op projectniveau. Nu wordt deze instelling automatisch ingeschakeld voor elk nieuw project en elke nieuwe organisatie die u maakt.
Notitie
De organisatie-instelling overschrijft de projectinstelling.
Als u deze instelling inschakelt in bestaande projecten en organisaties, kunnen bepaalde pijplijnen mislukken als uw pijplijnen toegang krijgen tot resources buiten het teamproject met behulp van toegangstokens. Als u pijplijnfouten wilt beperken, kunt u projectbuildserviceaccount expliciet toegang verlenen tot de gewenste resource. We raden u ten zeerste aan deze beveiligingsinstellingen in te schakelen.
Bepaalde machtigingen voor het toegangstoken verwijderen
Standaard verlenen we een aantal machtigingen aan het toegangstoken. Een van deze machtigingen is Queue Builds. Met deze update hebben we deze machtiging verwijderd voor het toegangstoken. Als uw pijplijnen deze machtiging nodig hebben, kunt u deze expliciet toewijzen aan het Project Build Service-account of projectverzamelingsserviceaccount, afhankelijk van het token dat u gebruikt.
Artefactcontrole evalueren
U kunt nu een set beleidsregels definiëren en de beleidsevaluatie toevoegen als controle op een omgeving voor artefacten voor containerinstallatiekopieën. Wanneer een pijplijn wordt uitgevoerd, wordt de uitvoering onderbroken voordat een fase wordt gestart die gebruikmaakt van de omgeving. Het opgegeven beleid wordt geëvalueerd op basis van de beschikbare metagegevens voor de installatiekopie die wordt geïmplementeerd. De controle wordt doorgegeven wanneer het beleid is geslaagd en markeert de fase als mislukt als de controle mislukt.
Ondersteuning voor Markdown in geautomatiseerde testfoutberichten
Markdown wordt nu ondersteund in foutberichten voor geautomatiseerde tests. U kunt eenvoudig foutberichten opmaken voor testuitvoering en testresultaat om de leesbaarheid te verbeteren en het oplossen van problemen in Azure Pipelines te vereenvoudigen. De ondersteunde Markdown-syntaxis vindt u hier.
Problemen vaststellen met Cron-schema's in YAML
We hebben een constante toename gezien in het gebruik van cron-syntaxis voor het opgeven van planningen in uw YAML-pijplijnen. Terwijl we naar uw feedback hebben geluisterd, hebben we gehoord dat het moeilijk was om te bepalen of Azure Pipelines uw syntaxis correct had verwerkt. Voorheen moet u wachten op de werkelijke tijd van de geplande uitvoering om problemen met de planning op te sporen. We hebben een nieuw actiemenu toegevoegd voor pijplijn om u te helpen bij het diagnosticeren van fouten in de vertakking/syntaxis. De geplande uitvoeringen in het menu Pijplijn uitvoeren geven u een voorbeeld van de komende geplande uitvoeringen voor uw pijplijn om u te helpen bij het diagnosticeren van fouten met uw cron-planningen.
Updates voor de arm-sjabloonimplementatietaak
Eerder hebben we de serviceverbindingen in de implementatietaak van de ARM-sjabloon niet gefilterd. Dit kan ertoe leiden dat de implementatie mislukt als u een serviceverbinding met een lager bereik selecteert om ARM-sjabloonimplementaties uit te voeren voor een breder bereik. We hebben nu het filteren van serviceverbindingen toegevoegd om serviceverbindingen met een lager bereik te filteren op basis van het implementatiebereik dat u kiest.
Beveiliging op projectniveau voor serviceverbindingen
Met deze update hebben we beveiliging op hubniveau toegevoegd voor serviceverbindingen. U kunt nu gebruikers toevoegen/verwijderen, rollen toewijzen en toegang beheren op een centrale locatie voor alle serviceverbindingen.
Ubuntu 18.04-pool
Azure Pipelines ondersteunt nu het uitvoeren van uw taken op Ubuntu 18.04. We hebben de door Microsoft gehoste Azure Pipelines-pool bijgewerkt met de ubuntu-18.04-installatiekopie. Wanneer u nu naar een pool in uw YAML-pijplijnen verwijst ubuntu-latest , betekent ubuntu-18.04 dit en niet ubuntu-16.04. U kunt nog steeds gebruikmaken van 16.04 afbeeldingen in uw taken met behulp van expliciete instructies ubuntu-16.04 .
Op de Service Mesh-interface gebaseerde canary-implementaties in KubernetesManifest-taak
Voorheen toen canary-strategie werd opgegeven in de KubernetesManifest-taak, zou de taak basislijn- en canary-workloads maken waarvan de replica's gelijk waren aan een percentage van de replica's die worden gebruikt voor stabiele workloads. Dit was niet precies hetzelfde als het splitsen van verkeer tot het gewenste percentage op aanvraagniveau. Om dit aan te pakken, hebben we ondersteuning toegevoegd voor canary-implementaties op basis van Service Mesh Interface aan de kubernetesManifest-taak.
Service Mesh Interface abstractie maakt plug-and-play configuratie mogelijk met service mesh providers zoals Linkerd en Istio. Nu neemt de KubernetesManifest-taak het harde werk weg van het toewijzen van TrafficSplit-objecten van SMI aan de stabiele, basislijn- en canary-services tijdens de levenscyclus van de implementatiestrategie. Het gewenste percentage splitsing van verkeer tussen stabiele, basislijn en kanarie zijn nauwkeuriger omdat het percentage verkeerssplitsing wordt beheerd op de aanvragen in het mesh-vlak van de service.
Hier volgt een voorbeeld van het uitvoeren van op SMI gebaseerde canary-implementaties op een rolling manier.
- deployment: Deployment
displayName: Deployment
pool:
vmImage: $(vmImage)
environment: ignite.smi
strategy:
canary:
increments: [25, 50]
preDeploy:
steps:
- task: KubernetesManifest@0
displayName: Create/update secret
inputs:
action: createSecret
namespace: smi
secretName: $(secretName)
dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
deploy:
steps:
- checkout: self
- task: KubernetesManifest@0
displayName: Deploy canary
inputs:
action: $(strategy.action)
namespace: smi
strategy: $(strategy.name)
trafficSplitMethod: smi
percentage: $(strategy.increment)
baselineAndCanaryReplicas: 1
manifests: |
manifests/deployment.yml
manifests/service.yml
imagePullSecrets: $(secretName)
containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
postRouteTraffic:
pool: server
steps:
- task: Delay@1
inputs:
delayForMinutes: '2'
ReviewApp in omgeving
ReviewApp implementeert elke pull-aanvraag vanuit uw Git-opslagplaats naar een dynamische omgevingsresource. Revisoren kunnen zien hoe deze wijzigingen eruitzien en werken met andere afhankelijke services voordat ze worden samengevoegd in de hoofdvertakking en worden geïmplementeerd in productie. Hierdoor kunt u eenvoudig reviewApp-resources maken en beheren en profiteren van alle traceerbaarheid en diagnosemogelijkheden van de omgevingsfuncties. Met behulp van het trefwoord reviewApp kunt u een kloon van een resource maken (dynamisch een nieuwe resource maken op basis van een bestaande resource in een omgeving) en de nieuwe resource toevoegen aan de omgeving.
Hier volgt een voorbeeld van een YAML-fragment voor het gebruik van reviewApp onder omgevingen.
jobs:
- deployment:
environment:
name: smarthotel-dev
resourceName: $(System.PullRequest.PullRequestId)
pool:
name: 'ubuntu-latest'
strategy:
runOnce:
pre-deploy:
steps:
- reviewApp: MasterNamespace
Azure Artifacts
Bijgewerkte ervaring voor Verbinding maken met feed
Het dialoogvenster Verbinding maken met feed is de ingang voor het gebruik van Azure Artifacts; het bevat informatie over het configureren van clients en opslagplaatsen voor het pushen en ophalen van pakketten uit feeds in Azure DevOps. We hebben het dialoogvenster bijgewerkt om gedetailleerde informatie over het instellen toe te voegen en de hulpprogramma's waarvoor we instructies geven, uitgebreid.
Openbare feeds zijn nu algemeen beschikbaar met upstreamondersteuning
De openbare preview van openbare feeds heeft geweldige acceptatie en feedback ontvangen. In deze update hebben we aanvullende functies uitgebreid tot algemene beschikbaarheid. U kunt nu een openbare feed instellen als een upstream-bron van een privéfeed. U kunt uw configuratiebestanden eenvoudig houden door zowel van en naar privé- als projectgerichte feeds te kunnen upstreamen.
Feeds met projectbereik maken vanuit de portal
Wanneer we openbare feeds hebben uitgebracht, hebben we ook feeds met projectbereik uitgebracht. Tot nu toe kunnen feeds met projectbereik worden gemaakt via REST API's of door een openbare feed te maken en vervolgens het project privé te maken. U kunt nu rechtstreeks in de portal feeds met projectbereik maken vanuit elk project als u over de vereiste machtigingen beschikt. U kunt ook zien welke feeds project zijn en welke binnen de organisatie vallen in de feedkiezer.
Rapportage
Een Sprint Burndown-widget met alles wat u hebt gevraagd
De nieuwe Widget Sprint Burndown ondersteunt het afbranden op verhaalpunten, het aantal taken of het optellen van aangepaste velden. U kunt zelfs een sprint-burndown maken voor Features of Epics. De widget geeft een gemiddelde burndown, % voltooid en toename van het bereik weer. U kunt het team configureren, zodat u sprint-burndowns voor meerdere teams op hetzelfde dashboard kunt weergeven. Met al deze geweldige informatie die u kunt weergeven, kunt u het formaat ervan wijzigen tot 10x10 op het dashboard.
Als u het wilt uitproberen, kunt u het toevoegen vanuit de widgetcatalogus of door de configuratie voor de bestaande Sprint Burndown-widget te bewerken en het selectievakje Nu de nieuwe versie proberen in te schakelen.
Notitie
De nieuwe widget maakt gebruik van Analytics. We hebben de verouderde Sprint Burndown bewaard voor het geval u geen toegang hebt tot Analytics.
Wiki
Synchrone scrolbewerking voor het bewerken van wikipagina's
Het bewerken van wikipagina's is nu eenvoudiger met synchrone scroll tussen de bewerking en het voorbeeldvenster. Als u aan de ene zijde schuift, schuift u automatisch naar de andere kant om de bijbehorende secties toe te wijzen. U kunt de synchrone schuif met de wisselknop uitschakelen.
Notitie
De status van de synchrone schuifknop wordt opgeslagen per gebruiker en organisatie.
Paginabezoeken voor wikipagina's
U kunt nu inzicht krijgen in de paginabezoeken voor wikipagina's. Met de REST API hebt u toegang tot de informatie over paginabezoeken in de afgelopen 30 dagen. U kunt deze gegevens gebruiken om rapporten te maken voor uw wikipagina's. Daarnaast kunt u deze gegevens opslaan in uw gegevensbron en dashboards maken om specifieke inzichten te krijgen, zoals top-n meest bekeken pagina's.
U ziet ook het aantal samengevoegde paginabezoeken voor de afgelopen 30 dagen op elke pagina.
Notitie
Een paginabezoek wordt gedefinieerd als een paginaweergave door een bepaalde gebruiker in een interval van 15 minuten.
Volgende stappen
Notitie
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 Help-menu om een probleem te melden of een suggestie op te geven.
U kunt ook advies krijgen en uw vragen beantwoorden door de community op Stack Overflow.
Met vriendelijke groet,
Jeff Beehler
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor