Ny widget för sprintnedbrändhet och förbättrad säkerhet för pipelines – Sprint 160 Update
I Sprint 160-uppdateringen av Azure DevOps lade vi till en ny widget för sprintnedbrändhet som stöder bränning efter artikelpunkter, antal uppgifter och genom att summera anpassade fält. Dessutom har vi förbättrat säkerheten för pipelines genom att begränsa omfattningen för åtkomsttoken.
Mer information finns i listan Funktioner nedan.
Nyheter i Azure DevOps
Funktioner
Azure Repos:
Azure Pipelines:
- Flerstegs-pipelines med UX
- Dirigera fördefinierad distributionsstrategi på miljöer för Kubernetes
- Godkännandeprinciper för YAML-pipelines
- ACR som en förstklassig pipelineresurs
- Metadata för pipeline-resurser som fördefinierade variabler
- Spårbarhet för pipelines och ACR-resurser
- Förenklad resursauktorisering i YAML-pipelines
- Förbättra säkerheten för pipelines genom att begränsa omfattningen för åtkomsttoken
- Utvärdera kontroll av artefakter
- Stöd för Markdown i automatiska testfelmeddelanden
- Diagnosticera cron-scheman i YAML
- Uppdateringar av distributionsuppgiften för ARM-mallen
- Säkerhet på projektnivå för tjänstanslutningar
- Ubuntu 18.04-pool
- Fördefinierade distributioner som baseras på Service Mesh-gränssnittet i KubernetesManifest-uppgift
- ReviewApp i miljö
Azure Artifacts:
- Uppdaterad anslutning till feed
- Offentliga feeds är nu allmänt tillgängliga med överordnad support
- Skapa projektomfattande feeds från portalen
Rapportering:
Wiki:
Azure-lagringsplatser
Administration av grenprinciper i olika lagringsplatser
Grenprinciper är en av de kraftfulla funktionerna i Azure Repos som hjälper dig att skydda viktiga grenar. Även om det finns möjlighet att ange principer på projektnivå i REST-API:et fanns det inget användargränssnitt för det. Nu kan administratörer ange principer för en specifik gren eller standardgrenen på alla lagringsplatser i projektet. En administratör kan till exempel kräva två minsta granskare för alla pull-begäranden som görs till varje huvudgren i varje lagringsplats i projektet. Du hittar funktionen Lägg till grenskydd i Projektinställningar för lagringsplatser.
Azure-pipelines
Flerstegs-pipelines med UX
Vi har arbetat med en uppdaterad användarupplevelse för att hantera dina pipelines. De här uppdateringarna gör att pipelines blir moderna och konsekventa med riktningen för Azure DevOps. Dessutom sammanför de här uppdateringarna klassiska byggpipelines och YAML-pipelines i flera steg till en enda upplevelse. Följande funktioner ingår till exempel i den nya upplevelsen. visa och hantera flera steg, godkänna pipelinekörningar, möjlighet att rulla hela vägen tillbaka i loggar medan en pipeline fortfarande pågår och hälsotillståndet per gren för en pipeline.
Tack till alla som har provat den nya upplevelsen. Om du inte har provat det aktiverar du pipelines i flera steg i förhandsversionsfunktionerna. Mer information om pipelines i flera steg finns i dokumentationen här .
Tack vare din feedback har vi tagit upp följande i de två senaste uppdateringarna.
- Identifiering av mappvyn.
- Jumpiness i loggvyn.
- Visa enkelt loggar från tidigare och aktuella aktiviteter även när en körning pågår.
- Gör det enklare att navigera mellan aktiviteter när du granskar loggar.
Kommentar
I nästa uppdatering planerar vi att aktivera den här funktionen som standard för alla. Du har fortfarande möjlighet att välja bort förhandsversionen. Några veckor efter det kommer funktionen att göras allmänt tillgänglig.
Dirigera fördefinierad distributionsstrategi på miljöer för Kubernetes
En av de viktigaste fördelarna med kontinuerlig leverans av programuppdateringar är möjligheten att snabbt skicka uppdateringar till produktion för specifika mikrotjänster. Detta ger dig möjlighet att snabbt svara på ändringar i affärskraven. Miljön introducerades som ett förstklassigt koncept som möjliggör orkestrering av distributionsstrategier och underlättar noll stilleståndstid. Tidigare stödde vi runOnce-strategin som utförde stegen en gång sekventiellt. Med stöd för kanariestrategi i pipelines i flera steg kan du nu minska risken genom att långsamt distribuera ändringen till en liten delmängd. När du får mer förtroende för den nya versionen kan du börja distribuera den till fler servrar i infrastrukturen och dirigera fler användare till den.
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...
Kanariestrategin för Kuberenetes distribuerar först ändringarna med 10 % poddar följt av 20 % vid övervakning av hälsotillståndet under postRouteTraffic. Om allt går bra kommer det att höjas till 100%.
Godkännandeprinciper för YAML-pipelines
I YAML-pipelines följer vi en konfiguration för resursägarkontrollerat godkännande. Resursägare konfigurerar godkännanden för resursen och alla pipelines som använder resurspausen för godkännanden innan steget börjar med att förbruka resursen. Det är vanligt att SOX-baserade programägare begränsar beställaren av distributionen från att godkänna sina egna distributioner.
Nu kan du använda avancerade godkännandealternativ för att konfigurera godkännandeprinciper som att beställaren inte ska godkänna, kräva godkännande från en delmängd av användare och tidsgränsen för godkännande.
ACR som en förstklassig pipelineresurs
Om du behöver använda en containeravbildning som publicerats till ACR (Azure Container Registry) som en del av pipelinen och utlösa pipelinen när en ny avbildning publiceras kan du använda ACR-containerresursen.
resources:
containers:
- container: MyACR #container resource alias
type: ACR
azureSubscription: RMPM #ARM service connection
resourceGroup: contosoRG
registry: contosodemo
repository: alphaworkz
trigger:
tags:
include:
- production
Dessutom kan ACR-bildmetadata nås med hjälp av fördefinierade variabler. Följande lista innehåller de ACR-variabler som är tillgängliga för att definiera en ACR-containerresurs i din pipeline.
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
Metadata för pipeline-resurser som fördefinierade variabler
Vi har lagt till fördefinierade variabler för YAML-pipelineresurser i pipelinen. Här är listan över tillgängliga pipelineresursvariabler.
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
Spårbarhet för pipelines och ACR-resurser
Vi säkerställer fullständig E2E-spårning när pipelines och ACR-containerresurser används i en pipeline. För varje resurs som förbrukas av YAML-pipelinen kan du spåra tillbaka till incheckningar, arbetsobjekt och artefakter.
I sammanfattningsvyn för pipelinekörning kan du se:
Den resursversion som utlöste körningen. Nu kan din pipeline utlösas när en annan Azure-pipelinekörning har slutförts eller när en containeravbildning skickas till ACR.
Incheckningar som förbrukas av pipelinen. Du kan också hitta uppdelningen av incheckningarna för varje resurs som förbrukas av pipelinen.
De arbetsobjekt som är associerade med varje resurs som förbrukas av pipelinen.
De artefakter som är tillgängliga för körningen.
I miljöns distributionsvy kan du se incheckningar och arbetsobjekt för varje resurs som distribueras till miljön.
Förenklad resursauktorisering i YAML-pipelines
En resurs är allt som används av en pipeline som ligger utanför pipelinen. Resurser måste auktoriseras innan de kan användas. Tidigare, när du använder obehöriga resurser i en YAML-pipeline, misslyckades den med ett resursauktoriseringsfel. Du var tvungen att auktorisera resurserna från sammanfattningssidan för den misslyckade körningen. Dessutom misslyckades pipelinen om den använde en variabel som refererade till en obehörig resurs.
Nu gör vi det enklare att hantera resursauktoriseringar. I stället för att misslyckas med körningen väntar körningen på behörigheter för resurserna i början av fasen som förbrukar resursen. En resursägare kan visa pipelinen och auktorisera resursen från sidan Säkerhet.
Förbättra säkerheten för pipelines genom att begränsa omfattningen för åtkomsttoken
Varje jobb som körs i Azure Pipelines får en åtkomsttoken. Åtkomsttoken används av uppgifterna och av dina skript för att anropa tillbaka till Azure DevOps. Vi använder till exempel åtkomsttoken för att hämta källkod, ladda upp loggar, testa resultat, artefakter eller för att göra REST-anrop till Azure DevOps. En ny åtkomsttoken genereras för varje jobb och upphör att gälla när jobbet har slutförts. Med den här uppdateringen har vi lagt till följande förbättringar.
Förhindra att token kommer åt resurser utanför ett teamprojekt
Hittills har standardomfånget för alla pipelines varit gruppprojektsamlingen. Du kan ändra omfånget så att det är gruppprojektet i klassiska byggpipelines. Du hade dock inte den kontrollen för den klassiska versionen eller YAML-pipelines. Med den här uppdateringen introducerar vi en organisationsinställning som tvingar varje jobb att hämta en token med projektomfattning oavsett vad som har konfigurerats i pipelinen. Vi har också lagt till inställningen på projektnivå. Nu kommer alla nya projekt och organisationer som du skapar automatiskt att ha den här inställningen aktiverad.
Kommentar
Organisationsinställningen åsidosätter projektinställningen.
Om du aktiverar den här inställningen i befintliga projekt och organisationer kan vissa pipelines misslyckas om dina pipelines får åtkomst till resurser som ligger utanför teamprojektet med hjälp av åtkomsttoken. För att undvika pipelinefel kan du uttryckligen bevilja Project Build Service-konto åtkomst till önskad resurs. Vi rekommenderar starkt att du aktiverar dessa säkerhetsinställningar.
Ta bort vissa behörigheter för åtkomsttoken
Som standard beviljar vi ett antal behörigheter till åtkomsttoken. En av de här behörigheterna är Köversioner. Med den här uppdateringen har vi tagit bort den här behörigheten till åtkomsttoken. Om dina pipelines behöver den här behörigheten kan du uttryckligen bevilja den till Project Build Service-kontot eller Project Collection Build Service-kontot beroende på vilken token du använder.
Utvärdera kontroll av artefakter
Nu kan du definiera en uppsättning principer och lägga till principutvärderingen som en kontroll av en miljö för containeravbildningsartefakter. När en pipeline körs pausas körningen innan en fas som använder miljön startas. Den angivna principen utvärderas mot tillgängliga metadata för avbildningen som distribueras. Kontrollen godkänns när principen lyckas och markerar fasen som misslyckad om kontrollen misslyckas.
Stöd för Markdown i automatiska testfelmeddelanden
Vi stöder nu Markdown i felmeddelanden för automatiserade tester. Du kan enkelt formatera felmeddelanden för både testkörning och testresultat för att förbättra läsbarheten och underlätta felsökningen av felet i Azure Pipelines. Markdown-syntaxen som stöds finns här.
Diagnosticera cron-scheman i YAML
Vi har sett en stadig ökning av användningen av cron-syntax för att ange scheman i YAML-pipelines. När vi lyssnade på din feedback hörde vi att det var svårt för dig att avgöra om Azure Pipelines hade bearbetat din syntax korrekt. Tidigare skulle du behöva vänta på den faktiska tiden för den schemalagda körningen för att felsöka schemaproblem. För att hjälpa dig att diagnostisera gren-/syntaxfel har vi lagt till en ny åtgärdsmeny för pipeline. Schemalagda körningar på menyn Kör pipeline ger dig en förhandsversion av de kommande schemalagda körningarna för din pipeline som hjälper dig att diagnostisera fel med dina cron-scheman.
Uppdateringar av distributionsuppgiften för ARM-mallen
Tidigare filtrerade vi inte tjänstanslutningarna i ARM-malldistributionsuppgiften. Detta kan leda till att distributionen misslyckas om du väljer en tjänstanslutning med lägre omfång för att utföra ARM-malldistributioner till ett bredare omfång. Nu har vi lagt till filtrering av tjänstanslutningar för att filtrera bort tjänstanslutningar med lägre omfattning baserat på det distributionsomfång du väljer.
Säkerhet på projektnivå för tjänstanslutningar
Med den här uppdateringen har vi lagt till säkerhet på hubbnivå för tjänstanslutningar. Nu kan du lägga till/ta bort användare, tilldela roller och hantera åtkomst på en central plats för alla tjänstanslutningar.
Ubuntu 18.04-pool
Azure Pipelines har nu stöd för att köra dina jobb på Ubuntu 18.04. Vi har uppdaterat Den Microsoft-värdbaserade Azure Pipelines-poolen så att den innehåller Ubuntu-18.04-avbildningen. Nu när du refererar till ubuntu-latest
poolen i dina YAML-pipelines betyder ubuntu-18.04
det och inte ubuntu-16.04
. Du kan fortfarande rikta in dig på 16,04 bilder i dina jobb med explicit.ubuntu-16.04
Fördefinierade distributioner som baseras på Service Mesh-gränssnittet i KubernetesManifest-uppgift
Tidigare när kanariestrategi angavs i KubernetesManifest-aktiviteten skulle uppgiften skapa baslinje- och kanariearbetsbelastningar vars repliker motsvarade en procentandel av replikerna som används för stabila arbetsbelastningar. Detta var inte exakt samma sak som att dela upp trafiken till önskad procentsats på begärandenivå. För att hantera detta har vi lagt till stöd för Service Mesh-gränssnittsbaserade kanariedistributioner till KubernetesManifest-uppgiften.
Abstraktion av Service Mesh-gränssnitt möjliggör plug-and-play-konfiguration med tjänstenätleverantörer som Linkerd och Istio. Nu tar KubernetesManifest-uppgiften bort det hårda arbetet med att mappa SMI:s TrafficSplit-objekt till stabila, baslinje- och kanarietjänster under distributionsstrategins livscykel. Den önskade procentuella uppdelningen av trafiken mellan stabil, baslinje och kanariefågel är mer exakt eftersom den procentuella trafikdelningen styrs på begäranden i service mesh-planet.
Följande är ett exempel på hur du utför SMI-baserade kanariedistributioner på ett löpande sätt.
- 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 i miljö
ReviewApp distribuerar varje pull-begäran från din Git-lagringsplats till en dynamisk miljöresurs. Granskare kan se hur dessa ändringar ser ut och fungerar med andra beroende tjänster innan de sammanfogas till huvudgrenen och distribueras till produktion. Detta gör det enkelt för dig att skapa och hantera reviewApp-resurser och dra nytta av alla funktioner för spårning och diagnos av miljöfunktionerna. Genom att använda nyckelordet reviewApp kan du skapa en klon av en resurs (dynamiskt skapa en ny resurs baserat på en befintlig resurs i en miljö) och lägga till den nya resursen i miljön.
Följande är ett YAML-exempelfragment med att använda reviewApp under miljöer.
jobs:
- deployment:
environment:
name: smarthotel-dev
resourceName: $(System.PullRequest.PullRequestId)
pool:
name: 'ubuntu-latest'
strategy:
runOnce:
pre-deploy:
steps:
- reviewApp: MasterNamespace
Azure Artifacts
Uppdaterad anslutning till feed
Dialogrutan Anslut till feed är startvägen till att använda Azure Artifacts. den innehåller information om hur du konfigurerar klienter och lagringsplatser för att skicka och hämta paket från feeds i Azure DevOps. Vi har uppdaterat dialogrutan för att lägga till detaljerad konfigurationsinformation och utökat de verktyg som vi ger instruktioner för.
Offentliga feeds är nu allmänt tillgängliga med överordnad support
Den offentliga förhandsversionen av offentliga feeds har fått bra implementering och feedback. I den här uppdateringen utökade vi ytterligare funktioner till allmän tillgänglighet. Nu kan du ange ett offentligt flöde som en uppströmskälla från ett privat flöde. Du kan hålla konfigurationsfilerna enkla genom att kunna uppströms både till och från privata feeds och projektomfattande feeds.
Skapa projektomfattande feeds från portalen
När vi släppte offentliga feeds släppte vi även feeds med projektomfattning. Hittills har projektomfattande feeds skapats via REST-API:er eller genom att skapa ett offentligt flöde och sedan göra projektet privat. Nu kan du skapa feeds med projektomfattning direkt i portalen från valfritt projekt om du har de behörigheter som krävs. Du kan också se vilka feeds som är projekt och vilka som är organisationsomfattande i feedväljaren.
Rapportering
En Sprint Burndown-widget med allt du har bett om
Den nya Sprint Burndown-widgeten har stöd för att bränna ned efter storypunkter, antal uppgifter eller genom att summera anpassade fält. Du kan till och med skapa en sprintbrännskada för funktioner eller epos. Widgeten visar genomsnittlig utbrändhet, % fullständig och omfångsökning. Du kan konfigurera teamet så att du kan visa sprintbränder för flera team på samma instrumentpanel. Med all denna fantastiska information att visa kan du ändra storlek på den upp till 10 x 10 på instrumentpanelen.
Om du vill prova kan du lägga till den från widgetkatalogen eller genom att redigera konfigurationen för den befintliga Sprint Burndown-widgeten och kontrollera rutan Prova den nya versionen nu .
Kommentar
Den nya widgeten använder Analytics. Vi behöll den äldre Sprint Burndown om du inte har åtkomst till Analytics.
Wiki
Synkron rullning för redigering av wiki-sidor
Det är nu enklare att redigera wiki-sidor med synkron rullning mellan redigerings- och förhandsgranskningsfönstret. Om du rullar på ena sidan rullas automatiskt den andra sidan för att mappa motsvarande avsnitt. Du kan inaktivera synkron rullning med växlingsknappen.
Kommentar
Tillståndet för den synkrona rullningsknappen sparas per användare och organisation.
Sidbesök till wiki-sidor
Nu kan du få insikter om sidbesöken för wiki-sidor. Med REST-API:et kan du komma åt informationen om sidbesök under de senaste 30 dagarna. Du kan använda dessa data för att skapa rapporter för dina wiki-sidor. Dessutom kan du lagra dessa data i din datakälla och skapa instrumentpaneler för att få specifika insikter som de mest visade sidorna i topp-n.
Du kommer också att se antalet aggregerade sidbesök för de senaste 30 dagarna på varje sida.
Kommentar
Ett sidbesök definieras som en sidvisning av en viss användare inom ett intervall på 15 minuter.
Nästa steg
Kommentar
Dessa funktioner kommer att distribueras under de kommande två till tre veckorna.
Gå över till Azure DevOps och ta en titt.
Så här ger du feedback
Vi vill gärna höra vad du tycker om de här funktionerna. Använd hjälpmenyn för att rapportera ett problem eller ge ett förslag.
Du kan också få råd och dina frågor som besvaras av communityn på Stack Overflow.
Tack,
Jeff Beehler