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:

• Administration av grenprinciper i olika lagringsplatser

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:

• En Sprint Burndown-widget med allt du har bett om

Wiki:

• Synkron rullning för redigering av wiki-sidor
• Sidbesök till wiki-sidor

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.

1. Identifiering av mappvyn.
2. Jumpiness i loggvyn.
3. Visa enkelt loggar från tidigare och aktuella aktiviteter även när en körning pågår.
4. 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.

Gå till Azure DevOps

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