Nuovo widget di burndown sprint e sicurezza migliorata delle pipeline - Aggiornamento sprint 160

Nell'aggiornamento sprint 160 di Azure DevOps è stato aggiunto un nuovo widget di burndown sprint che supporta la combustione in base ai punti di storia, al numero di attività e alla somma dei campi personalizzati. Abbiamo inoltre migliorato la sicurezza delle pipeline limitando l'ambito dei token di accesso.

Per altre informazioni, vedere l'elenco delle funzionalità riportato di seguito.

Novità di Azure DevOps

Funzionalità

Azure Repos:

• Amministrazione dei criteri dei rami tra repository

Azure Pipelines:

• Esperienza utente per le pipeline a più fasi
• Orchestrare una strategia di distribuzione canary nell'ambiente per Kubernetes
• Criteri di approvazione per le pipeline YAML
• Registro Azure Container come risorsa della pipeline di prima classe
• Metadati delle risorse delle pipeline come variabili predefinite
• Tracciabilità per le pipeline e le risorse del Registro Azure Container
• Autorizzazione semplificata per le risorse nelle pipeline YAML
• Migliorare la sicurezza delle pipeline limitando l'ambito dei token di accesso
• Controllo di valutazione degli artefatti
• Supporto per il markdown nei messaggi di errore dei test automatizzati
• Diagnosticare le pianificazioni Cron in YAML
• Aggiornamenti all'attività di distribuzione del modello di Resource Manager
• Sicurezza a livello di progetto per le connessioni del servizio
• Pool di Ubuntu 18.04
• Distribuzioni canary basate su interfaccia del mesh del servizio nell'attività KubernetesManifest
• ReviewApp nell'ambiente

Azure Artifacts:

• Aggiornamento dell'esperienza di connessione al feed
• I feed pubblici sono ora disponibili a livello generale con supporto upstream
• Creare feed con ambito specifico per un progetto dal portale

Reporting:

• Un widget Sprint Burndown con tutto quello che hai chiesto

Wiki:

• Scorrimento sincrono per la modifica delle pagine wiki
• Collegamenti permanenti per pagine wiki

Azure Repos

Amministrazione dei criteri dei rami tra repository

I criteri di ramo sono una delle potenti funzionalità di Azure Repos che consentono di proteggere rami importanti. Anche se la possibilità di impostare criteri a livello di progetto esiste nell'API REST, non esiste un'interfaccia utente. A questo punto, gli amministratori possono impostare criteri in un ramo specifico o nel ramo predefinito in tutti i repository nel progetto. Ad esempio, un amministratore potrebbe richiedere due revisori minimi per tutte le richieste pull effettuate in ogni ramo principale in ogni repository nel progetto. È possibile trovare la funzionalità Aggiungi protezione ramo nelle impostazioni del progetto Repos.

Azure Pipelines

Esperienza utente per le pipeline a più fasi

È stata creata un'esperienza utente aggiornata per gestire le pipeline. Questi aggiornamenti rendono le pipeline moderne e coerenti con la direzione di Azure DevOps. Inoltre, questi aggiornamenti riuniscono pipeline di compilazione classiche e pipeline YAML a più fasi in un'unica esperienza. Ad esempio, le funzionalità seguenti sono incluse nella nuova esperienza; visualizzazione e gestione di più fasi, approvazione delle esecuzioni della pipeline, possibilità di scorrere tutto il tempo nei log mentre una pipeline è ancora in corso e integrità per ramo di una pipeline.

Grazie a tutti coloro che hanno provato la nuova esperienza. Se non è stato provato, abilitare le pipeline a più fasi nelle funzionalità di anteprima. Per altre informazioni sulle pipeline a più fasi, vedere la documentazione qui .

Grazie ai commenti e suggerimenti, abbiamo affrontato quanto segue negli ultimi due aggiornamenti.

1. Individuabilità della visualizzazione cartelle.
2. Salto nella visualizzazione log.
3. Mostra facilmente i log delle attività precedenti e correnti anche quando un'esecuzione è in corso.
4. Semplifica la navigazione tra le attività durante la revisione dei log.

Nota

Nell'aggiornamento successivo si prevede di attivare questa funzionalità per impostazione predefinita per tutti. Sarà comunque possibile rifiutare esplicitamente l'anteprima. Alcune settimane dopo, la funzionalità verrà resa disponibile a livello generale.

Orchestrare una strategia di distribuzione canary nell'ambiente per Kubernetes

Uno dei vantaggi principali del recapito continuo degli aggiornamenti delle applicazioni è la possibilità di eseguire rapidamente il push degli aggiornamenti nell'ambiente di produzione per microservizi specifici. In questo modo è possibile rispondere rapidamente alle modifiche apportate ai requisiti aziendali. L'ambiente è stato introdotto come concetto di prima classe che abilita l'orchestrazione delle strategie di distribuzione e facilita le versioni senza tempi di inattività. In precedenza, è stata supportata la strategia runOnce che ha eseguito i passaggi una volta in sequenza. Con il supporto per la strategia canary nelle pipeline a più fasi, è ora possibile ridurre il rischio implementando lentamente la modifica in un piccolo subset. Man mano che si ottiene maggiore fiducia nella nuova versione, è possibile iniziare a implementarlo in più server nell'infrastruttura e instradare altri utenti a tale versione.

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

La strategia canary per Kuberenetes distribuirà prima le modifiche con il 10% dei pod seguiti dal 20% durante il monitoraggio dell'integrità durante il postRouteTraffic. Se tutto va bene, promuoverà al 100%.

Criteri di approvazione per le pipeline YAML

Nelle pipeline YAML viene seguita una configurazione di approvazione controllata dal proprietario della risorsa. I proprietari delle risorse configurano le approvazioni per la risorsa e tutte le pipeline che usano la risorsa sospesa per le approvazioni prima dell'inizio della fase che usa la risorsa. È comune per i proprietari di applicazioni basate su SOX limitare il richiedente della distribuzione dall'approvazione delle proprie distribuzioni.

È ora possibile usare opzioni di approvazione avanzate per configurare criteri di approvazione come il richiedente non deve approvare, richiedere l'approvazione da un subset di utenti e timeout di approvazione.

Registro Azure Container come risorsa della pipeline di prima classe

Se è necessario usare un'immagine del contenitore pubblicata in Registro Azure Container (Registro Azure Container) come parte della pipeline e attivare la pipeline ogni volta che viene pubblicata una nuova immagine, è possibile usare la risorsa contenitore registro Azure Container.

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

È inoltre possibile accedere ai metadati delle immagini del Registro Azure Container usando variabili predefinite. L'elenco seguente include le variabili del Registro Azure Container disponibili per definire una risorsa contenitore del Registro Azure Container nella 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

Metadati delle risorse delle pipeline come variabili predefinite

Sono state aggiunte variabili predefinite per le risorse delle pipeline YAML nella pipeline. Di seguito è riportato l'elenco delle variabili delle risorse della pipeline disponibili.

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

Tracciabilità per le pipeline e le risorse del Registro Azure Container

Si garantisce la tracciabilità completa di E2E quando le pipeline e le risorse del contenitore del Registro Azure Container vengono usate in una pipeline. Per ogni risorsa utilizzata dalla pipeline YAML, è possibile risalire ai commit, agli elementi di lavoro e agli artefatti.

Nella visualizzazione di riepilogo dell'esecuzione della pipeline è possibile visualizzare:

• Versione della risorsa che ha attivato l'esecuzione. È ora possibile attivare la pipeline al completamento di un'altra esecuzione di una pipeline di Azure o quando viene eseguito il push di un'immagine del contenitore in Registro Azure Container.

  

• Commit utilizzati dalla pipeline. È anche possibile trovare la suddivisione dei commit da ogni risorsa utilizzata dalla pipeline.

  

• Elementi di lavoro associati a ogni risorsa utilizzata dalla pipeline.

• Artefatti disponibili per l'utilizzo da parte dell'esecuzione.

  

Nella visualizzazione distribuzioni dell'ambiente è possibile visualizzare i commit e gli elementi di lavoro per ogni risorsa distribuita nell'ambiente.

Autorizzazione semplificata per le risorse nelle pipeline YAML

Una risorsa è qualsiasi elemento usato da una pipeline esterna alla pipeline. Le risorse devono essere autorizzate prima di poterle usare. In precedenza, quando si usano risorse non autorizzate in una pipeline YAML, si è verificato un errore di autorizzazione della risorsa. È stato necessario autorizzare le risorse dalla pagina di riepilogo dell'esecuzione non riuscita. Inoltre, la pipeline non è riuscita se usava una variabile che faceva riferimento a una risorsa non autorizzata.

Ora è più semplice gestire le autorizzazioni delle risorse. Invece di non riuscire l'esecuzione, l'esecuzione attenderà le autorizzazioni per le risorse all'inizio della fase che utilizza la risorsa. Un proprietario della risorsa può visualizzare la pipeline e autorizzare la risorsa dalla pagina Sicurezza.

Migliorare la sicurezza delle pipeline limitando l'ambito dei token di accesso

Ogni processo eseguito in Azure Pipelines ottiene un token di accesso. Il token di accesso viene usato dalle attività e dagli script per richiamare azure DevOps. Ad esempio, si usa il token di accesso per ottenere il codice sorgente, caricare log, risultati di test, artefatti o effettuare chiamate REST in Azure DevOps. Viene generato un nuovo token di accesso per ogni processo e scade al termine del processo. Con questo aggiornamento sono stati aggiunti i miglioramenti seguenti.

• Impedire al token di accedere alle risorse all'esterno di un progetto team

  Fino ad ora, l'ambito predefinito di tutte le pipeline era la raccolta di progetti team. È possibile modificare l'ambito in modo che sia il progetto team nelle pipeline di compilazione classiche. Tuttavia, non si dispone di tale controllo per le pipeline YAML o di versione classica. Con questo aggiornamento si introduce un'impostazione dell'organizzazione per forzare ogni processo a ottenere un token con ambito progetto indipendentemente da ciò che è configurato nella pipeline. È stata aggiunta anche l'impostazione a livello di progetto. Ora, ogni nuovo progetto e organizzazione creato avrà automaticamente questa impostazione attivata.

  Nota

  L'impostazione dell'organizzazione sostituisce l'impostazione del progetto.

  Se si attiva questa impostazione nei progetti e nelle organizzazioni esistenti, alcune pipeline potrebbero non riuscire se le pipeline accedono a risorse esterne al progetto team usando token di accesso. Per attenuare gli errori della pipeline, è possibile concedere in modo esplicito all'account del servizio di compilazione del progetto l'accesso alla risorsa desiderata. È consigliabile attivare queste impostazioni di sicurezza.

• Rimuovere determinate autorizzazioni per il token di accesso

  Per impostazione predefinita, viene concessa una serie di autorizzazioni al token di accesso, una di queste autorizzazioni è La compilazione coda. Con questo aggiornamento, questa autorizzazione è stata rimossa per il token di accesso. Se le pipeline necessitano di questa autorizzazione, è possibile concederla in modo esplicito all'account del servizio di compilazione progetto o all'account del servizio di compilazione della raccolta di progetti a seconda del token usato.

Controllo di valutazione degli artefatti

È ora possibile definire un set di criteri e aggiungere la valutazione dei criteri come controllo in un ambiente per gli artefatti dell'immagine del contenitore. Quando viene eseguita una pipeline, l'esecuzione viene sospesa prima di avviare una fase che usa l'ambiente. I criteri specificati vengono valutati rispetto ai metadati disponibili per l'immagine distribuita. Il controllo viene superato quando il criterio ha esito positivo e contrassegna la fase come non riuscita se il controllo ha esito negativo.

Supporto per il markdown nei messaggi di errore dei test automatizzati

Ora è supportato Markdown nei messaggi di errore per i test automatizzati. È possibile formattare facilmente i messaggi di errore sia per l'esecuzione dei test che per il risultato del test per migliorare la leggibilità e semplificare la risoluzione degli errori in Azure Pipelines. La sintassi Markdown supportata è disponibile qui.

Diagnosticare le pianificazioni Cron in YAML

È stato rilevato un aumento costante dell'uso della sintassi cron per specificare le pianificazioni nelle pipeline YAML. Durante l'ascolto dei commenti e suggerimenti, è stato rilevato che è stato difficile determinare se Azure Pipelines ha elaborato correttamente la sintassi. In precedenza, è necessario attendere l'ora effettiva dell'esecuzione pianificata per eseguire il debug dei problemi di pianificazione. Per diagnosticare gli errori di ramo/sintassi, è stato aggiunto un nuovo menu di azione per la pipeline. L'esecuzione pianificata nel menu Esegui pipeline fornirà un'anteprima delle prossime esecuzioni pianificate per la pipeline per diagnosticare gli errori con le pianificazioni cron.

Aggiornamenti all'attività di distribuzione del modello di Resource Manager

In precedenza, le connessioni al servizio non erano filtrate nell'attività di distribuzione del modello di Resource Manager. Ciò può causare un errore nella distribuzione se si seleziona una connessione al servizio con ambito inferiore per eseguire distribuzioni di modelli di Resource Manager in un ambito più ampio. È stato ora aggiunto il filtro delle connessioni al servizio per filtrare le connessioni al servizio con ambito inferiore in base all'ambito di distribuzione scelto.

Sicurezza a livello di progetto per le connessioni del servizio

Con questo aggiornamento è stata aggiunta la sicurezza a livello di hub per le connessioni al servizio. È ora possibile aggiungere/rimuovere utenti, assegnare ruoli e gestire l'accesso in una posizione centralizzata per tutte le connessioni al servizio.

Pool di Ubuntu 18.04

Azure Pipelines supporta ora l'esecuzione dei processi in Ubuntu 18.04. Il pool di Azure Pipelines ospitato da Microsoft è stato aggiornato per includere l'immagine Ubuntu-18.04. Ora, quando si fa riferimento ubuntu-latest al pool nelle pipeline YAML, significa ubuntu-18.04 e non ubuntu-16.04. È comunque possibile specificare come destinazione le immagini 16.04 nei processi usando ubuntu-16.04 in modo esplicito.

Distribuzioni canary basate su interfaccia del mesh del servizio nell'attività KubernetesManifest

In precedenza, quando è stata specificata la strategia canary nell'attività KubernetesManifest, l'attività creava carichi di lavoro di base e canary le cui repliche erano uguali a una percentuale delle repliche usate per carichi di lavoro stabili. Ciò non equivale esattamente alla suddivisione del traffico fino alla percentuale desiderata a livello di richiesta. Per risolvere questo problema, è stato aggiunto il supporto per le distribuzioni canary basate su Service Mesh Interface all'attività KubernetesManifest.

L'astrazione dell'interfaccia service mesh consente la configurazione plug-and-play con provider di mesh di servizi, ad esempio Linkerd e Istio. L'attività KubernetesManifest elimina ora il duro lavoro di mapping degli oggetti TrafficSplit di SMI ai servizi stable, baseline e canary durante il ciclo di vita della strategia di distribuzione. La percentuale desiderata di suddivisione del traffico tra stabile, baseline e canary è più accurata poiché la percentuale di suddivisione del traffico viene controllata sulle richieste nel piano mesh di servizio.

Di seguito è riportato un esempio di esecuzione di distribuzioni canary basate su SMI in modo in sequenza.

- 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 nell'ambiente

ReviewApp distribuisce ogni richiesta pull dal repository Git a una risorsa di ambiente dinamico. I revisori possono vedere l'aspetto di tali modifiche e lavorare con altri servizi dipendenti prima di essere uniti nel ramo principale e distribuiti nell'ambiente di produzione. In questo modo sarà più semplice creare e gestire le risorse reviewApp e trarre vantaggio da tutte le funzionalità di tracciabilità e diagnosi delle funzionalità dell'ambiente. Usando la parola chiave reviewApp , è possibile creare un clone di una risorsa (creare dinamicamente una nuova risorsa in base a una risorsa esistente in un ambiente) e aggiungere la nuova risorsa all'ambiente.

Di seguito è riportato un frammento YAML di esempio relativo all'uso di reviewApp in ambienti.

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MasterNamespace

Azure Artifacts

Aggiornamento dell'esperienza di connessione al feed

La finestra di dialogo Connetti al feed è l'ingresso all'uso di Azure Artifacts; contiene informazioni su come configurare client e repository per eseguire il push e il pull dei pacchetti dai feed in Azure DevOps. La finestra di dialogo è stata aggiornata per aggiungere informazioni dettagliate sulla configurazione ed è stata estesa l'estensione degli strumenti per cui vengono fornite le istruzioni.

I feed pubblici sono ora disponibili a livello generale con supporto upstream

L'anteprima pubblica dei feed pubblici ha ricevuto un'ottima adozione e feedback. In questo aggiornamento sono stati estese funzionalità aggiuntive alla disponibilità generale. È ora possibile impostare un feed pubblico come origine upstream da un feed privato. È possibile mantenere i file di configurazione semplici grazie alla possibilità di eseguire l'upstream di feed privati e con ambito progetto.

Creare feed con ambito specifico per un progetto dal portale

Quando sono stati rilasciati feed pubblici, sono stati rilasciati anche feed con ambito progetto. Fino ad ora, i feed con ambito progetto potrebbero essere creati tramite API REST o creando un feed pubblico e quindi trasformando il progetto privato. È ora possibile creare feed con ambito progetto direttamente nel portale da qualsiasi progetto se si dispone delle autorizzazioni necessarie. È anche possibile vedere quali feed sono progetti e quali sono con ambito organizzazione nello strumento di selezione feed.

Creazione di report

Un widget Sprint Burndown con tutto quello che hai chiesto

Il nuovo widget Sprint Burndown supporta la combustione in base ai punti story, al conteggio delle attività o alla somma dei campi personalizzati. È anche possibile creare un burndown sprint per Funzionalità o Epiche. Il widget visualizza il burndown medio, % completato e l'aumento dell'ambito. È possibile configurare il team, consentendo di visualizzare i burndown sprint per più team nello stesso dashboard. Con tutte queste informazioni utili da visualizzare, è possibile ridimensionarla fino a 10x10 nel dashboard.

Per provarlo, è possibile aggiungerlo dal catalogo dei widget o modificando la configurazione per il widget Sprint Burndown esistente e selezionando la casella Prova la nuova versione.

Nota

Il nuovo widget usa Analytics. Il burndown sprint legacy è stato mantenuto nel caso in cui non si abbia accesso ad Analytics.

Wiki

Scorrimento sincrono per la modifica delle pagine wiki

La modifica delle pagine wiki è ora più semplice con lo scorrimento sincrono tra la modifica e il riquadro di anteprima. Lo scorrimento su un lato scorre automaticamente l'altro lato per mappare le sezioni corrispondenti. È possibile disabilitare lo scorrimento sincrono con l'interruttore.

Nota

Lo stato dell'interruttore di scorrimento sincrono viene salvato per utente e organizzazione.

Collegamenti permanenti per pagine wiki

È ora possibile ottenere informazioni dettagliate sulle visite alle pagine wiki. L'API REST consente di accedere alle informazioni di visita della pagina negli ultimi 30 giorni. È possibile usare questi dati per creare report per le pagine wiki. È anche possibile archiviare questi dati nell'origine dati e creare dashboard per ottenere informazioni dettagliate specifiche come le prime n pagine più visualizzate.

Verrà inoltre visualizzato un conteggio delle visite di pagina aggregate per gli ultimi 30 giorni in ogni pagina.

Nota

Una visita di pagina è definita come visualizzazione pagina da un determinato utente in un intervallo di 15 minuti.

Passaggi successivi

Nota

Queste funzionalità verranno implementate nelle prossime due o tre settimane.

Passare ad Azure DevOps e dare un'occhiata.

Passare ad Azure DevOps

Come fornire commenti e suggerimenti

Ci piacerebbe sentire ciò che pensi a queste funzionalità. Usare il menu ? per segnalare un problema o fornire un suggerimento.

È anche possibile ottenere consigli e risposte alle domande della community su Stack Overflow.

Grazie,

Jeff Beehler