Condividi tramite

Nuovi report di Analisi e app Azure Boards per Slack - Aggiornamento sprint 155

  • Articolo

Nell'aggiornamento dello Sprint 155 di Azure DevOps vengono introdotti nuovi report di Azure Boards per semplificare la verifica di metriche importanti relative al team. Potrai vedere i nuovi report nella scheda Analisi degli hub di Boards, Backlog e Sprint. Questi report sono completamente interattivi e puoi modificarli per soddisfare le tue esigenze specifiche.

Siamo inoltre felici di annunciare la nuova app di Azure Boards per Slack. Questa app ti permetterà di monitorare le attività degli elementi di lavoro e di creare elementi di lavoro dal tuo canale Slack.

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

Novità di Azure DevOps

Funzionalità

Generale:

Azure Boards:

Azure Repos:

Azure Artifacts:

Azure Pipelines:

   Pipeline YAML a più fasi

  VM ospitate

Kubernetes

  Test

  Esperienze di Azure

Integrazioni

Generali

Invitare collaboratori di GitHub in Azure DevOps

È ora possibile invitare i collaboratori da GitHub ad Azure DevOps quando si è connessi con l'identità GitHub. È possibile cercare e invitare altri utenti di GitHub dalla home page di Project e dalla pagina Utenti nelle impostazioni organizzazione.

Invite GitHub collaborators into Azure DevOps.

Questa funzionalità deve essere abilitata per le organizzazioni esistenti tramite un'impostazione in Criteri nelle impostazioni organizzazione. Tuttavia, è attivata per impostazione predefinita per le organizzazioni create da un'identità GitHub.

Enable for existing organizations.

Nota

Questa funzionalità non è disponibile per gli utenti non GitHub, anche se il criterio è attivato.

Per altre informazioni sull'invito dei membri del team, vedere la documentazione qui. Se si verificano problemi di connessione ad Azure DevOps tramite GitHub, vedere le domande frequenti sulla risoluzione dei problemi di autenticazione e invito degli utenti di GitHub.

Azure Boards

Ottenere informazioni dettagliate sullo stato del team con tre nuovi report di Azure Boards

Non è possibile correggere ciò che non è possibile visualizzare. Pertanto, si vuole tenere d'occhio lo stato e l'integrità dei processi di lavoro. Con questi report, è più semplice tenere traccia delle metriche importanti con un minimo sforzo in Azure Boards.

I tre nuovi report interattivi sono: Burndown, Diagramma di flusso cumulativo (CFD) e Velocità. È possibile visualizzare i report nella nuova scheda di analisi.

Le metriche come il burndown sprint, il flusso di lavoro e la velocità del team offrono visibilità sullo stato di avanzamento del team e consentono di rispondere a domande come:

  • Quanto lavoro abbiamo lasciato in questo sprint? Siamo in pista per completarlo?
  • Quale passaggio del processo di sviluppo richiede più tempo? Possiamo fare qualcosa su di esso?
  • In base alle iterazioni precedenti, quanto lavoro è necessario pianificare per il prossimo sprint?

Nota

I grafici mostrati in precedenza nelle intestazioni sono stati sostituiti con questi report avanzati.

I nuovi report sono completamente interattivi e consentono di adattarli alle proprie esigenze. I nuovi report sono disponibili nella scheda Analisi in ogni hub.

  • Il grafico burn-down è disponibile nell'hub Sprint .

    Analytics tab in Sprint hub.

  • È possibile accedere ai report CFD e Velocity dalla scheda Analisi in Bacheche e Backlog facendo clic sulla scheda pertinente.

    CFD and velocity reports in boards.

Con i nuovi report si hanno più controllo e informazioni sul team. Di seguito sono riportati alcuni esempi.

  • I report Sprint Burndown e Velocity possono essere impostati per usare il conteggio degli elementi di lavoro o la somma del lavoro rimanente.
  • È possibile modificare l'intervallo di tempo del burndown dello sprint senza influire sulle date del progetto. Pertanto, se il team trascorre in genere il primo giorno di ogni pianificazione dello sprint, è ora possibile trovare una corrispondenza con il grafico per riflettere tale situazione.
  • Il grafico Burndown ora ha una filigrana che mostra i fine settimana.
  • Il report CFD consente di rimuovere le colonne della lavagna, ad esempio Progettazione, per concentrarsi maggiormente sul flusso su cui i team hanno il controllo.

Di seguito è riportato un esempio del report CFD che mostra il flusso per gli ultimi 30 giorni del backlog Stories.

Example of the CFD report.

È ora possibile tenere traccia del grafico Velocità per tutti i livelli di backlog. Ad esempio, è ora possibile aggiungere funzionalità e epiche, mentre prima del grafico precedente sono supportati solo i requisiti. Di seguito è riportato un esempio di report sulla velocità per le ultime 6 iterazioni del backlog Funzionalità.

Example of a velocity report.

App di Azure Boards per Slack

Siamo lieti di annunciare la nuova app Azure Boards per Slack. Con questa app è possibile monitorare l'attività degli elementi di lavoro e creare elementi di lavoro dal canale Slack.

L'app consente di configurare e gestire sottoscrizioni di eventi, tra cui la creazione e gli aggiornamenti degli elementi di lavoro e di ricevere notifiche per questi eventi nel canale Slack. Le conversazioni nel canale Slack possono essere usate per creare elementi di lavoro. Riceverai anche notifiche personali quando ti vengono assegnati elementi di lavoro. Inoltre, le anteprime per gli URL degli elementi di lavoro consentiranno di avviare discussioni.

Azure Boards app for Slack.

Per installare l'app Azure Boards, fare clic qui.

Personalizzare le colonne di Taskboard

Microsoft è lieta di annunciare che è stata aggiunta un'opzione per personalizzare le colonne nella Lavagna attività. È ora possibile aggiungere, rimuovere, rinominare e riordinare le colonne.

Per configurare le colonne nella scheda attività, passare a Opzioni colonna.

Customizing columns on the taskboard.

Questa funzionalità è stata assegnata in ordine di priorità in base a un suggerimento della community degli sviluppatori.

Attivare/Disattivare per mostrare o nascondere gli elementi di lavoro figlio completati nel backlog

Molte volte, quando si affina il backlog, si vogliono visualizzare solo gli elementi che non sono stati completati. È ora possibile visualizzare o nascondere gli elementi figlio completati nel backlog.

Se l'interruttore è attivato, verranno visualizzati tutti gli elementi figlio in uno stato completato. Quando l'interruttore è disattivato, tutti gli elementi figlio in uno stato completato verranno nascosti dal backlog.

Show or hide child items on the backlog.

È ora possibile accedere facilmente alle schede visitate di recente, ai backlog, alle query e agli sprint dalla casella di ricerca attivando la casella di ricerca in Azure Boards.

Activate the instant search box.

È anche possibile cercare le bacheche, i backlog, le query e gli sprint nel progetto digitando il nome della scheda nella casella di ricerca. Ora, le bacheche che contano di più per voi sono solo un clic di distanza.

Search for a board name.

Tag più recenti visualizzati durante l'assegnazione di tag a un elemento di lavoro

Quando si contrassegna un elemento di lavoro, l'opzione di completamento automatico verrà ora visualizzata fino a cinque dei tag usati più di recente. In questo modo sarà più semplice aggiungere le informazioni corrette agli elementi di lavoro.

Most recent used tags displayed when tagging a work item.

Azure Repos

Opzioni migliorate per i filtri di ricerca del codice

In precedenza, la ricerca di codice supportava filtri di ricerca di codice 39, ad esempio commento: e def:. I dati hanno suggerito che non sono stati usati molti filtri, pertanto vengono rimossi alcuni filtri e unendo altri. Con questo aggiornamento è stato ridotto il numero di filtri a 19. Ciò consentirà di rendere le query di ricerca del codice più efficienti e ridurre il disordine nell'interfaccia.

Code search filter options.

Ad esempio, ora func: esegue il mapping al metodo: ad esempio se si cerca func:Account Amministrazione, i risultati verranno mappati al metodo:Account Amministrazione. Analogamente macrodef: e macroref: vengono mappati a macro:. D'altra parte, i filtri come l'unione: e l'organizzazione: sono stati deprecati a causa della mancanza di uso.

Metriche per code coverage e criteri di ramo per le richieste pull

È ora possibile visualizzare le metriche di code coverage per le modifiche all'interno della visualizzazione pull request (PR). In questo modo è possibile verificare le modifiche in modo adeguato tramite test automatizzati. Lo stato della copertura verrà visualizzato come commento nella panoramica della richiesta pull. È possibile visualizzare i dettagli delle informazioni di copertura per ogni riga di codice modificata nella visualizzazione diff del file.

Code coverage metrics and branch policy for pull requests

View details of coverage information for every code line that is changed.

Inoltre, i proprietari del repository possono ora impostare criteri di code coverage e impedire l'unione di modifiche di grandi dimensioni e non sottoposte a test in un ramo. È possibile definire le soglie di copertura desiderate in un azurepipelines-coverage.yml file di impostazioni archiviato nella radice del repository e dei criteri di copertura usando il criterio di configurazione esistente di un ramo per funzionalità aggiuntive dei servizi in Azure Repos.

Define coverage thresholds.

Filtrare le notifiche relative ai commenti dalle richieste pull

I commenti nelle richieste pull spesso possono generare un sacco di rumore a causa delle notifiche. È stata aggiunta una sottoscrizione personalizzata che consente di filtrare le notifiche di commento sottoscritte in base all'età dei commenti, al commento, al commento eliminato, agli utenti menzionati, all'autore della richiesta pull, al ramo di destinazione e ai partecipanti al thread. È possibile creare queste sottoscrizioni di notifica facendo clic sull'icona utente nell'angolo in alto a destra e passando a Impostazioni utente.

Filter comment notifications from pull requests.

Filter comment notifications in User settings.

Hook del servizio per commenti per le richieste pull

È ora possibile creare hook del servizio per i commenti in una richiesta pull in base al repository e al ramo di destinazione.

Service hooks for pull request comments.

Azure Artifacts

Condividere pubblicamente i pacchetti con i feed pubblici (anteprima)

È ora possibile creare e archiviare i pacchetti all'interno di feed pubblici. I pacchetti archiviati all'interno di feed pubblici sono disponibili per tutti gli utenti su Internet senza autenticazione, indipendentemente dal fatto che si trovino o meno nell'organizzazione o addirittura connessi a un'organizzazione di Azure DevOps. Per altre informazioni sui feed pubblici, vedere la documentazione dei feed o passare direttamente all'esercitazioneper condividere i pacchetti pubblicamente.

Share your packages with public feeds.

Azure Pipelines

Comandi kustomize e kompose come opzioni bake nell'attività KubernetesManifest

kustomize (parte di Kubernetes sig-cli) consente di personalizzare i file YAML non elaborati e senza modelli per più scopi e lasciare invariato il file YAML originale. È stata aggiunta un'opzione per kustomize nell'azione bake dell'attività KubernetesManifest in modo che qualsiasi cartella contenente file kustomization.yaml possa essere usata per generare i file manifesto usati nell'azione di distribuzione dell'attività KubernetesManifest.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

kompose trasformerà un file Docker Compose in una risorsa Kubernetes.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Supporto per le credenziali di amministratore cluster nell'attività HelmDeploy

In precedenza, l'attività HelmDeploy usava le credenziali utente del cluster per le distribuzioni. Ciò ha comportato richieste di accesso interattive e pipeline con errori per un cluster abilitato per il controllo degli accessi in base al ruolo basato su Azure Active Directory. Per risolvere questo problema, è stata aggiunta una casella di controllo che consente di usare le credenziali di amministratore del cluster anziché le credenziali utente del cluster.

Package and deploy Helm charts showing the use cluster admin credentials checkbox.

Gestire le variabili delle pipeline nell'editor YAML

È stata aggiornata l'esperienza per la gestione delle variabili della pipeline nell'editor YAML. Non è più necessario passare all'editor classico per aggiungere o aggiornare variabili nelle pipeline YAML.

Manage pipeline variables in YAML editor.

Nuove variabili predefinite nella pipeline YAML

Le variabili offrono un modo conveniente di ottenere bit di chiave dei dati in varie parti della pipeline. Con questo aggiornamento sono state aggiunte alcune variabili predefinite a un processo di distribuzione. Queste variabili vengono impostate automaticamente dal sistema, con ambito per il processo di distribuzione specifico e di sola lettura.

  • Environment.Id : ID dell'ambiente.
  • Environment.Name: nome dell'ambiente di destinazione del processo di distribuzione.
  • Environment.ResourceId: ID della risorsa nell'ambiente di destinazione del processo di distribuzione.
  • Environment.ResourceName: nome della risorsa nell'ambiente di destinazione del processo di distribuzione.

Attualmente, è possibile collegare automaticamente gli elementi di lavoro alle compilazioni classiche. Tuttavia, questo non è stato possibile con le pipeline YAML. Con questo aggiornamento, abbiamo risolto questo divario. Quando si esegue correttamente una pipeline usando codice da un ramo specificato, Azure Pipelines assocerà automaticamente l'esecuzione a tutti gli elementi di lavoro ( che vengono dedotti tramite i commit in tale codice). Quando si apre l'elemento di lavoro, sarà possibile visualizzare le esecuzioni in cui è stato compilato il codice per l'elemento di lavoro. Per configurare questa operazione, usare il pannello delle impostazioni di una pipeline.

Annullare una fase in una esecuzione di pipeline YAML a più fasi

Quando si esegue una pipeline YAML a più fasi, è ora possibile annullare l'esecuzione di una fase mentre è in corso. Ciò è utile se si sa che la fase avrà esito negativo o se si ha un'altra esecuzione che si vuole avviare. Questa funzionalità è anche un prerequisito per supportare la ripetizione di una fase non riuscita in futuro.

Approvazioni nelle pipeline YAML a più fasi

Continuiamo a migliorare le pipeline YAML a più fasi, ora è possibile aggiungere approvazioni manuali a queste pipeline. I proprietari dell'infrastruttura possono proteggere i propri ambienti e cercare approvazioni manuali prima di una fase in qualsiasi pipeline li distribuisce. Con la separazione completa dei ruoli tra i proprietari dell'infrastruttura (ambiente) e dell'applicazione (pipeline), si garantisce che la firma manuale per la distribuzione in una particolare pipeline e il controllo centrale nell'applicazione degli stessi controlli in tutte le distribuzioni all'ambiente.

Approvals in multi-stage YAML pipelines.

Le esecuzioni della pipeline distribuite nello sviluppo si arresteranno per l'approvazione all'inizio della fase.

Pipeline runs deploying to dev will stop for approval.

Updates to hosted pipelines images (Aggiornamenti alle immagini di pipeline ospitate)

Sono stati apportati aggiornamenti a diverse immagini di macchine virtuali ospitate in Azure Pipelines. Altre informazioni sulle versioni più recenti sono disponibili qui. Nell'ambito di questo aggiornamento sono state aggiunte le modifiche seguenti:

  • Per VS2017 e VS2019:

    • Aggiunta di Azul Java 7
    • Immagini Docker memorizzate nella cache aggiunte per trovare la corrispondenza con la versione del kernel host
    • Aggiunta del modulo Az PowerShell v2.3.2
    • Aggiunta di Mercurial alla versione 5.0.0
    • Aggiornamento di Python alle versioni 2.7.16, 3.4.4, 3.5.4, 3.6.8, 3.7.4
    • Aggiunta della libreria di classi portabile (solo VS 2019)
    • Modifica dei percorsi predefiniti e delle variabili di ambiente di Rust

  • Per Ubuntu 16.04:

    • Aggiornato helm per eseguire sempre il pull più recente (non più aggiunto alla versione 2.14.0)
    • Aggiunta di diversi contenitori Docker più diffusi
    • Aggiornamento di Python alle versioni 2.7.16, 3.4.10, 3.5.7, 3.6.9, 3.7.4
    • Modifica dei percorsi predefiniti e delle variabili di ambiente di Rust

  • Per tutte le immagini, aggiunta di una ImageVersion variabile di ambiente per la versione dell'immagine

Per un elenco completo degli strumenti disponibili per una particolare immagine, vedere Impostazioni > Dettagli pool > di agenti.

Miglioramenti al Progetto DevOps per le macchine virtuali

In questo aggiornamento è stato migliorato il flusso di lavoro della macchina virtuale (VM) devOps Projects per includere le macchine virtuali che non sono conformi alla restrizione per ogni quota di posizione. In precedenza era necessario scegliere la macchina virtuale in base al nome e all'offerta. Ora è disponibile una visualizzazione su richiesta con altri dettagli sulle offerte di macchine virtuali, ad esempio costi/mese, RAM, dischi dati e così via. In questo modo è più semplice selezionare la macchina virtuale necessaria.

Enhancements to DevOps Project for virtual machine.

Singolo pool ospitato

Nell'ultimo sprint è stato comunicato che è in corso l'implementazione di un nuovo pool ospitato denominato Azure Pipelines per sostituire tutti gli altri pool ospitati- Hosted VS2017, Hosted Ubuntu 1604, Hosted Windows 2019 con VS2019, hosted macOS e hosted macOS High Sierra. Questa modifica verrà implementata con questa versione.

La presenza di più pool ospitati può generare confusione a volte. Non si ottiene un'immagine accurata della posizione in cui viene utilizzata la concorrenza. Ad esempio, se si dispone di una concorrenza di 10 processi paralleli, vengono visualizzati 10 agenti virtuali in ognuno dei pool ospitati, che non sono accurati. Quando il processo è in attesa di un pool ospitato specifico (ad esempio, Hosted VS2017) con tutti gli agenti inattivi, si potrebbe pensare che il servizio Azure Pipelines sia interrotto senza rendersi conto che la concorrenza è probabilmente usata in altri pool ospitati (ad esempio, ospitato Ubuntu 1604).

Con questa modifica, verrà visualizzato un singolo pool ospitato che offre un'immagine accurata del numero di processi in esecuzione in tale pool. Si prevede di implementare questa modifica nei prossimi sprint. Non sarà necessario apportare modifiche alle pipeline perché i processi verranno reindirizzati automaticamente dai pool ospitati precedenti all'immagine appropriata nel nuovo pool unificato.

Mostrare le informazioni corrette relative al pool in ogni processo

In precedenza, quando è stata usata una matrice per espandere i processi o una variabile per identificare un pool, si è verificato un problema durante la visualizzazione delle informazioni corrette sul pool nelle pagine dei log. Con questo aggiornamento sono stati risolti i problemi che causano la visualizzazione di informazioni non corrette sul pool per determinati processi.

Supporto nel prodotto per la gestione dei test inattendibili

I test flaky possono influire sulla produttività degli sviluppatori perché gli errori di test potrebbero non essere correlati alle modifiche sottoposte a test. Possono anche influire sulla qualità del codice spedito. Questo è il motivo per cui è stato aggiunto il supporto in-product per la gestione dei test flaky. Questa funzionalità supporta il ciclo di vita end-to-end con rilevamento, creazione di report e risoluzione. La gestione dei test flaky supporta il rilevamento di sistema e personalizzato.

Il rilevamento del sistema è disponibile tramite la funzionalità di riesecuzione dell'attività VSTest. Un test in flaky è un test che fornisce risultati diversi, ad esempio il superamento o l'esito negativo, anche quando non sono presenti modifiche nel codice sorgente o nell'ambiente di esecuzione. Tutte le altre esecuzioni di test per lo stesso ramo vengono contrassegnate anche come instabilità fino a quando non vengono risolte e non contrassegnate. È anche possibile collegare il meccanismo di rilevamento personalizzato usando le API. Una volta identificato un test come instabilità, è possibile ottenere i dettagli nel report di test nel contesto nella pipeline. È quindi possibile decidere se i test instabilità influisce sull'errore della pipeline. Per impostazione predefinita, le informazioni sui test in flaky sono disponibili come metadati aggiuntivi.

In-product support for flaky test management.

Di seguito è riportato un esempio di report con il riepilogo del test.

Example of a report with the test summary.

Per altre informazioni sulla gestione dei test in formato flaky, vedere la documentazione qui.

Miglioramenti al Centro distribuzione per l'app Web nel portale di Azure

Il Centro distribuzione per WebApp è stato migliorato nel portale di Azure con il supporto per le pipeline con più artefatti. A questo punto, se un artefatto non primario di Azure Pipelines viene distribuito nell'app Web, si otterranno i dettagli pertinenti dal portale di Azure. Si avrà anche un collegamento diretto al repository distribuito per passare direttamente al repository dal portale di Azure. Il repository può essere ospitato in Azure Repos o in GitHub.

Trigger di integrazione continua per i nuovi rami

È stata una richiesta lunga in sospeso per non attivare compilazioni CI quando viene creato un nuovo ramo e quando tale ramo non ha modifiche. Vedi gli esempi seguenti:

  • Usare l'interfaccia Web per creare un nuovo ramo basato su un ramo esistente. Verrà attivata immediatamente una nuova compilazione CI se il filtro del ramo corrisponde al nome del nuovo ramo. Ciò è indesiderato perché il contenuto del nuovo ramo è lo stesso rispetto al ramo esistente.
  • Si dispone di un repository con due cartelle: app e documenti. È stato configurato un filtro di percorso per l'integrazione continua in modo che corrisponda a "app". In altre parole, non si vuole creare una nuova compilazione se è stato eseguito il push di una modifica nella documentazione. Creare un nuovo ramo in locale, apportare alcune modifiche alla documentazione e quindi eseguire il push di tale ramo nel server. È stato usato per attivare una nuova compilazione CI. Questo è indesiderato perché è stato chiesto esplicitamente di non cercare le modifiche nella cartella docs. Tuttavia, a causa del modo in cui è stato gestito un nuovo evento di ramo, sembra che sia stata apportata anche una modifica alla cartella dell'app.

A questo punto, abbiamo un modo migliore per gestire l'integrazione continua per i nuovi rami per risolvere questi problemi. Quando si pubblica un nuovo ramo, vengono cercati in modo esplicito nuovi commit in tale ramo e si controlla se corrispondono ai filtri di percorso.

Integrazione di Terraform con Azure Pipelines

Terraform è uno strumento open source per lo sviluppo, la modifica e il controllo delle versioni dell'infrastruttura in modo sicuro ed efficiente. Terraform codifica le API in file di configurazione dichiarativi che consentono di definire e effettuare il provisioning dell'infrastruttura usando un linguaggio di configurazione di alto livello. È possibile usare l'estensione Terraform per creare risorse in tutti i principali provider di infrastruttura: Azure, Amazon Web Services (AWS) e Google Cloud Platform (GCP).

Per altre informazioni sull'estensione Terraform, vedere la documentazione qui.

Terraform integration with Azure Pipelines.

Integrazione con Google Analytics

Il framework degli esperimenti di Google Analytics consente di testare quasi qualsiasi modifica o variazione in un sito Web o un'app per misurare l'impatto su un obiettivo specifico. Ad esempio, potresti avere attività che vuoi che gli utenti completino (ad esempio, effettuare un acquisto, iscriversi a una newsletter) e/o metriche che vuoi migliorare (ad esempio, ricavi, durata sessione, frequenza di rimbalzo). Queste attività consentono di identificare le modifiche da implementare in base all'impatto diretto sulle prestazioni della funzionalità.

L'estensione esperimenti di Google Analytics per Azure DevOps aggiunge passaggi di sperimentazione alle pipeline di compilazione e rilascio, in modo da poter scorrere in modo continuo, apprendere e distribuire a un ritmo accelerato gestendo gli esperimenti su base continua, ottenendo tutti i vantaggi di DevOps da Azure Pipelines.

È possibile scaricare l'estensione esperimenti di Google Analytics dal Marketplace.

Integration with Google Analytics.

Memorizzazione di pipeline nella cache (anteprima pubblica)

La memorizzazione nella cache della pipeline consente di salvare i risultati di un'operazione a esecuzione prolungata, ad esempio un ripristino del pacchetto o una compilazione delle dipendenze, e ripristinarli durante l'esecuzione successiva di una pipeline. Ciò può comportare compilazioni più veloci.

Per altri dettagli, vedere il post di blog con l'annuncio completo qui.

Comandi per gruppi di variabili e gestione di variabili delle pipeline

Può essere difficile convertire le pipeline basate su YAML da un progetto a un altro perché è necessario configurare manualmente le variabili della pipeline e i gruppi di variabili. Tuttavia, con i comandi di gestione delle variabili della pipeline e del gruppo di variabili, è ora possibile creare script per la configurazione e la gestione delle variabili e dei gruppi di variabili che a loro volta possono essere controllati dalla versione, consentendo di condividere facilmente le istruzioni per spostare e configurare pipeline da un progetto a un altro.

Eseguire una pipeline per un ramo di esecuzione di pipeline

Quando si crea una richiesta pull, può essere difficile verificare se le modifiche potrebbero interrompere l'esecuzione della pipeline nel ramo di destinazione. Tuttavia, con la possibilità di attivare un'esecuzione della pipeline o di accodare una compilazione per un ramo di richiesta pull, è ora possibile convalidare e visualizzare le modifiche in corso eseguendola sulla pipeline di destinazione. Per altre informazioni, vedere az pipelines run e az pipelines build queue command documentation (comando az pipelines run e az pipelines build queue ).

Ignorare la prima esecuzione della pipeline

Quando si creano pipeline, a volte si vuole creare ed eseguire il commit di un file YAML e non attivare l'esecuzione della pipeline perché può causare un'esecuzione difettosa a causa di un'ampia gamma di motivi: l'infrastruttura non è pronta o deve creare e aggiornare gruppi di variabili/variabili e così via. Con l'interfaccia della riga di comando di Azure DevOps è ora possibile ignorare la prima esecuzione automatizzata della pipeline durante la creazione di una pipeline includendo il parametro --skip-first-run. Per altre informazioni, vedere la documentazione del comando az pipeline create.

Miglioramento del comando dell'endpoint di servizio

I comandi dell'interfaccia della riga di comando dell'endpoint di servizio supportano solo azure rm e l'endpoint di servizio github configurati e di gestione. Tuttavia, con questa versione, i comandi dell'endpoint di servizio consentono di creare qualsiasi endpoint di servizio fornendo la configurazione tramite file e fornisce comandi ottimizzati: az devops service-endpoint github e az devops service-endpoint azurerm, che forniscono il supporto di prima classe per creare endpoint di servizio di questi tipi. Per altre informazioni, vedere la documentazione del comando.

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 commenti e suggerimenti per segnalare un problema o fornire un suggerimento.

Make a suggestion

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

Grazie,

Sam Guckheimer