Share via

Ny widget för att bränna ned sprint och förbättrad säkerhet för pipelines – Sprint 160-uppdatering

  • Artikel

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 omfånget för åtkomsttoken.

Mer information finns i listan Funktioner nedan.

Nyheter i Azure DevOps

Funktioner

Azure-lagringsplatser:

Azure Pipelines:

Azure Artifacts:

Rapportering:

Wiki:

Azure-lagringsplatser

Principadministration mellan lagringsplatser

Förgreningsprinciper ä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 viss 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 på varje lagringsplats i projektet. Du hittar funktionen Lägg till grenskydd i Projektinställningar för lagringsplatser.

Principadministration mellan lagringsplatser.

Azure-pipelines

Flerstegspipelines UX

Vi har arbetat med en uppdaterad användarupplevelse för att hantera dina pipelines. De här uppdateringarna gör pipelines moderna och konsekventa med riktningen för Azure DevOps. Dessutom sammanför de här uppdateringarna klassiska bygg-pipelines och YAML-pipelines i flera steg i en enda upplevelse. Följande funktioner ingår till exempel i den nya upplevelsen. visa och hantera flera faser, godkänna pipelinekörningar, möjlighet att rulla hela vägen tillbaka i loggar medan en pipeline fortfarande pågår och status 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örhandsgranskningsfunktionerna. Mer information om pipelines i flera steg finns i dokumentationen här .

Flerstegspipelines UX.

Tack vare din feedback har vi tagit upp följande i de två senaste uppdateringarna.

  1. Det går att identifiera mappvyn.
  2. Jumpiness i loggvyn.
  3. Visa loggar från tidigare och aktuella uppgifter även när en körning pågår.
  4. Gör det enklare att navigera mellan aktiviteter när du granskar loggar.

Funktioner som ingår i den nya upplevelsen.

Anteckning

I nästa uppdatering planerar vi att aktivera den här funktionen som standard för alla. Du kommer fortfarande att ha möjlighet att välja bort förhandsversionen. Några veckor efter det blir funktionen allmänt tillgänglig.

Orkestrera distributionsstrategi för kanariegrupper i miljön 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 nedtidsversioner. Tidigare hade vi stöd för runOnce-strategin som utförde stegen en gång i följd. 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%.

Vi letar efter tidig feedback om stöd för VM-resurser i miljöer och utför en rullande distributionsstrategi på flera datorer. Kontakta oss för att registrera dig.

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 resursen pausa för godkännanden innan den fas som använder resursen börjar. Det är vanligt att SOX-baserade programägare begränsar begäranden av distributionen från att godkänna sina egna distributioner.

Du kan nu använda avancerade godkännandealternativ för att konfigurera godkännandeprinciper som beställare inte bör godkänna, kräva godkännande från en delmängd av användare och tidsgräns för godkännande.

Godkännandeprinciper för YAML-pipelines.

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 din pipeline och utlösa pipelinen när en ny avbildning har publicerats 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

Pipelineresursmetadata som fördefinierade variabler

Vi har lagt till fördefinierade variabler för YAML-pipelinesresurser 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årbarhet när pipelines och ACR-containerresurser används i en pipeline. För varje resurs som används av din YAML-pipeline kan du spåra tillbaka till incheckningar, arbetsobjekt och artefakter.

I sammanfattningsvyn för pipelinekörningen 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.

    Resursversion som utlöste körningen.

  • De incheckningar som förbrukas av pipelinen. Du kan också hitta uppdelningen av incheckningarna för varje resurs som förbrukas av pipelinen.

    Incheckningar 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.

    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.

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 det 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örenklad resursauktorisering i YAML-pipelines.

Förbättra pipelinesäkerheten genom att begränsa åtkomsttokens omfång

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 får åtkomst till resurser utanför ett teamprojekt

    Hittills har standardomfånget för alla pipelines varit teamprojektsamlingen. Du kan ändra omfånget så att det blir teamprojektet i klassiska bygg-pipelines. 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 konfigureras i pipelinen. Vi har också lagt till inställningen på projektnivå. Nu är den här inställningen aktiverad för alla nya projekt och organisationer som du skapar automatiskt.

    Anteckning

    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 dessa behörigheter ä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-tjänstkontot eller project collection build-tjänstkontot beroende på vilken token du använder.

Utvärdera artefaktkontroll

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.

Utvärdera artefaktkontroll.

Markdown-stöd 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.

Markdown-stöd i automatiska testfelmeddelanden.

Diagnostisera Cron-scheman i YAML

Vi har sett en stadig ökning av användningen av cron-syntax för att ange scheman i dina 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 fel med gren/syntax har vi lagt till en ny åtgärdsmeny för pipelinen. Med menyn Schemalagda körningar på menyn Kör pipeline får du en förhandsgranskning av de kommande schemalagda körningarna för din pipeline som hjälper dig att diagnostisera fel med dina cron-scheman.

Diagnostisera Cron-scheman i YAML.

Uppdateringar till 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 omfång 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.

Säkerhet på projektnivå för tjänstanslutningar.

Ubuntu 18.04-pool

Azure Pipelines stöder nu körning av jobb på Ubuntu 18.04. Vi har uppdaterat Den Microsoft-värdbaserade Azure Pipelines-poolen med Ubuntu-18.04-avbildningen. När du refererar till ubuntu-latest poolen i dina YAML-pipelines betyder ubuntu-18.04 det nu och inte ubuntu-16.04. Du kan fortfarande rikta in dig på 16,04 bilder i dina jobb med explicit.ubuntu-16.04

Service Mesh-gränssnittsbaserade kanariedistributioner i KubernetesManifest-uppgift

Tidigare när kanariestrategi angavs i KubernetesManifest-aktiviteten skulle aktiviteten skapa baslinje- och kanariearbetsbelastningar vars repliker motsvarade en procentandel av replikerna som användes 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änssnittet möjliggör plug-and-play-konfiguration med tjänstnätsleverantö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 kanarie är mer exakt eftersom den procentuella trafikdelningen styrs på begäranden i servicenätplanet.

Följande är ett exempel på hur du utför SMI-baserade kanariedistributioner på ett rullande 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 slås samman i 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 där du använder 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

Connect to feed-upplevelsen har uppdaterats

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 överordnat stöd

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 dina konfigurationsfiler enkla genom att kunna uppströms både till och från privata feeds och projektomfattande feeds.

Skapa feeds med projektomfattning från portalen

När vi släppte offentliga feeds släppte vi även feeds med projektomfång. Hittills har projektomfattande feeds kunnat skapas 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 Story Points, 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 ökning av omfång. Du kan konfigurera teamet så att du kan visa sprintnedslag för flera team på samma instrumentpanel. Med all denna fantastiska information som ska visas kan du ändra storlek på den upp till 10 x 10 på instrumentpanelen.

Sprint Burndown widget.

Om du vill prova det kan du lägga till det från widgetkatalogen eller genom att redigera konfigurationen för den befintliga Sprint Burndown-widgeten och markera rutan Prova den nya versionen nu .

Anteckning

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 redigeringen 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.

Synkron rullning för redigering av wiki-sidor.

Anteckning

Tillståndet för den synkrona rullningsväxlingsknappen sparas per användare och organisation.

Sidbesök för 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 ser också antalet aggregerade sidbesök för de senaste 30 dagarna på varje sida.

Sidbesök för wiki-sidor.

Anteckning

Ett sidbesök definieras som en sidvisning av en viss användare inom ett intervall på 15 minuter.

Nästa steg

Anteckning

De här funktionerna kommer att lanseras under de kommande två till tre veckorna.

Gå till Azure DevOps och ta en titt.

Gå till Azure DevOps

Så här ger du feedback

Vi vill gärna höra vad du tycker om dessa funktioner. Använd hjälpmenyn för att rapportera ett problem eller ge ett förslag.

Ge ett förslag

Du kan också få råd och dina frågor som besvaras av communityn på Stack Overflow.

Tack,

Jeff Beehler