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, il conteggio delle attività e la somma dei campi personalizzati. Inoltre, è stata migliorata la sicurezza delle pipeline limitando l'ambito dei token di accesso.

Per altre informazioni, vedere l'elenco Funzionalità riportate di seguito.

Novità di Azure DevOps

Funzionalità

Azure Repos:

• Amministrazione dei criteri di ramo tra repository

Azure Pipelines:

• Esperienza utente di pipeline a più fasi
• Orchestrare la 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
• Meta-dati delle risorse della pipeline come variabili predefinite
• Tracciabilità per le pipeline e le risorse del Registro Azure Container
• Autorizzazione semplificata delle risorse nelle pipeline YAML
• Migliorare la sicurezza della pipeline limitando l'ambito dei token di accesso
• Valutare il controllo dell'artefatto
• Supporto markdown nei messaggi di errore di test automatizzati
• Diagnosi delle pianificazioni cron in YAML
• Aggiornamenti all'attività di distribuzione del modello di Resource Manager
• Sicurezza a livello di progetto per le connessioni al servizio
• Pool Ubuntu 18.04
• Distribuzioni canary basate su Interfaccia mesh del servizio nell'attività KubernetesManifest
• RivediApp nell'ambiente

Azure Artifacts:

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

Creazione di report:

• Widget Sprint Burndown con tutto ciò che si sta chiedendo

Wiki:

• Scorrimento sincrono per la modifica delle pagine wiki
• Visite di pagine per le pagine wiki

Azure Repos

Amministrazione dei criteri di ramo 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 i criteri a livello di progetto esiste nell'API REST, non esiste alcuna 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 di pipeline a più fasi

Si è lavorato su 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 mettono insieme 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 tutti i passaggi nei log mentre una pipeline è ancora in corso e l'integrità per ramo di una pipeline.

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

Grazie al tuo feedback, abbiamo affrontato quanto segue negli ultimi due aggiornamenti.

1. Individuabilità della visualizzazione cartelle.
2. Salto nella visualizzazione log.
3. Visualizzare i log dalle attività precedenti e correnti anche quando un'esecuzione è in corso.
4. Semplifica lo spostamento 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 la strategia di distribuzione canary nell'ambiente per Kubernetes

Uno dei vantaggi principali della distribuzione continua degli aggiornamenti dell'applicazione è la possibilità di eseguire rapidamente il push degli aggiornamenti nella produzione per microservizi specifici. In questo modo è possibile rispondere rapidamente ai cambiamenti nei requisiti aziendali. L'ambiente è stato introdotto come concetto di prima classe che abilita l'orchestrazione delle strategie di distribuzione e facilita le versioni di inattività zero. 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 multi-stage, è ora possibile ridurre il rischio eseguendo lentamente la distribuzione della modifica a un piccolo subset. Man mano che si ottiene maggiore attendibilità nella nuova versione, è possibile iniziare a implementarla in più server nell'infrastruttura e indirizzare più utenti a esso.

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 distribuisce prima le modifiche con i pod del 10% seguiti dal 20% durante il monitoraggio dell'integrità durante il postRouteTraffic. Se tutto va bene, promuoverà il 100%.

Si stanno cercando commenti e suggerimenti iniziali sul supporto per le risorse delle macchine virtuali negli ambienti e l'esecuzione di una strategia di distribuzione in sequenza tra più computer. Contattaci per registrarci .

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 nella risorsa e tutte le pipeline che usano la risorsa sospendeno per le approvazioni prima dell'inizio della fase che utilizza la risorsa. È comune per i proprietari di applicazioni basate su SOX limitare la richiesta della distribuzione da approvare le proprie distribuzioni.

È ora possibile usare opzioni di approvazione avanzate per configurare i criteri di approvazione come il richiedente non devono 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 è stata pubblicata una nuova immagine, è possibile usare la risorsa contenitore ACR.

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 meta-dati dell'immagine 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

Meta-dati delle risorse della pipeline come variabili predefinite

Nella pipeline sono state aggiunte variabili predefinite per le pipeline YAML. Ecco l'elenco delle variabili di risorsa 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 tornare ai commit, agli elementi di lavoro e agli artefatti.

Nella visualizzazione 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 pipeline di Azure o quando viene eseguito il push di un'immagine del contenitore in ACR.

  

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

• Gli artefatti disponibili per essere usati dall'esecuzione.

  

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

Autorizzazione semplificata delle risorse nelle pipeline YAML

Una risorsa è qualsiasi elemento usato da una pipeline esterna alla pipeline. Le risorse devono essere autorizzate prima che possano essere usate. In precedenza, quando si usano risorse non autorizzate in una pipeline YAML, non è stato possibile eseguire un errore di autorizzazione delle risorse. È necessario autorizzare le risorse dalla pagina di riepilogo dell'esecuzione non riuscita. Inoltre, la pipeline non è riuscita se usa una variabile che fa riferimento a una risorsa non autorizzata.

È ora possibile gestire più facilmente 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 di risorse può visualizzare la pipeline e autorizzare la risorsa dalla pagina Sicurezza.

Migliorare la sicurezza della 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 eseguire nuovamente la chiamata ad Azure DevOps. Ad esempio, viene usato il token di accesso per ottenere il codice sorgente, caricare i log, i risultati di test, gli artefatti o eseguire chiamate REST in Azure DevOps. Un nuovo token di accesso viene generato 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 a questo momento, 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 è stato disponibile tale controllo per le pipeline YAML o versione classica. Con questo aggiornamento viene presentata un'impostazione dell'organizzazione per forzare ogni processo per 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 esegue l'override dell'impostazione del progetto.

  L'attivazione di questa impostazione nei progetti e nelle organizzazioni esistenti può causare un errore di determinate pipeline se le pipeline accedono alle risorse esterne al progetto team usando i token di accesso. Per attenuare gli errori della pipeline, è possibile concedere in modo esplicito l'accesso dell'account del servizio di compilazione del progetto 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 è Compilazione coda. Con questo aggiornamento, è stata rimossa questa autorizzazione per il token di accesso. Se le pipeline richiedono 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.

Valutare il controllo dell'artefatto

È ora possibile definire un set di criteri e aggiungere la valutazione dei criteri come controllo su 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. Il criterio specificato viene valutato rispetto ai metadati disponibili per la distribuzione dell'immagine. Il controllo passa quando il criterio ha esito positivo e contrassegna la fase come non riuscita se il controllo ha esito negativo.

Supporto markdown nei messaggi di errore di test automatizzati

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

Diagnosi delle pianificazioni cron in YAML

Si è visto un aumento costante dell'uso della sintassi cron per specificare le pianificazioni nelle pipeline YAML. Come abbiamo ascoltato il feedback, abbiamo sentito che è stato difficile determinare se Azure Pipelines aveva 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 branch/sintassi, è stato aggiunto un nuovo menu azione per la pipeline. Le esecuzioni pianificate nel menu Esegui pipeline offrono 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 non sono stati filtrate le connessioni al servizio nell'attività di distribuzione dei modelli di Resource Manager. Ciò può comportare un errore nella distribuzione se si seleziona una connessione del 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 di servizio con ambito inferiore in base all'ambito di distribuzione scelto.

Sicurezza a livello di progetto per le connessioni al 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 un luogo centralizzato per tutte le connessioni al servizio.

Pool Ubuntu 18.04

Azure Pipelines supporta ora l'esecuzione dei processi in Ubuntu 18.04. È stato aggiornato il pool di Azure Pipelines ospitato da Microsoft 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 eseguire la destinazione di 16.04 immagini nei processi usando ubuntu-16.04 in modo esplicito.

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

In precedenza, quando la strategia canary è stata specificata nell'attività KubernetesManifest, l'attività creerebbe carichi di lavoro baseline e canary le cui repliche equivalevano a una percentuale delle repliche usate per carichi di lavoro stabili. Ciò non corrisponde 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 per l'attività KubernetesManifest.

L'astrazione dell'interfaccia di Service Mesh consente la configurazione plug-and-play con provider di mesh del servizio, ad esempio Linkerd e Istio. Ora l'attività KubernetesManifest elimina il duro lavoro del mapping degli oggetti TrafficSplit di SMI ai servizi stabile, 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 perché la divisione del traffico percentuale viene controllata sulle richieste nel piano della mesh del 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'

RivediApp nell'ambiente

ReviewApp distribuisce ogni richiesta pull dal repository Git a una risorsa di ambiente dinamica. I revisori possono verificare come tali modifiche siano presenti e funzionino con altri servizi dipendenti prima di essere uniti al ramo principale e distribuiti nella produzione. In questo modo è possibile creare e gestire le risorse reviewApp e trarre vantaggio da tutte le funzionalità di tracciabilità e diagnosi delle funzionalità di 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 di codice YAML di esempio dell'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 per l'uso di Elementi di Azure; contiene informazioni su come configurare client e repository per eseguire il push e il pull di pacchetti da feed in Azure DevOps. La finestra di dialogo è stata aggiornata per aggiungere informazioni dettagliate sulla configurazione ed è stato espanso gli strumenti per cui vengono fornite le istruzioni.

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

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

Creare feed con ambito progetto dal portale

Quando sono stati rilasciati feed pubblici, sono stati rilasciati anche feed con ambito progetto. Fino a questo momento, i feed con ambito progetto possono 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 visualizzare quali feed sono progetti e quali sono con ambito organizzazione nella selezione feed.

Reporting

Widget Sprint Burndown con tutto ciò che si sta chiedendo

Il nuovo widget Sprint Burndown supporta la combustione in base ai punti story, al conteggio delle attività o alla somma di campi personalizzati. È anche possibile creare un burndown sprint per Funzionalità o Epics. Il widget visualizza un burndown medio, % completo e un 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 oppure 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 il pulsante disattiva.

Nota

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

Visite di pagine per le pagine wiki

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

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

Nota

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

Passaggi successivi

Nota

Queste funzionalità verranno implementate nei prossimi due-tre settimane.

Passare ad Azure DevOps e guardare.

Passare ad Azure DevOps

Come fornire commenti e suggerimenti

Ci piacerebbe sentire quello che pensi a queste funzionalità. Usare il menu della Guida per segnalare un problema o fornire un suggerimento.

È anche possibile ottenere consigli e domande risposte dalla community in Stack Overflow.

Grazie,

Jeff Beehler