Condividi tramite

Note sulla versione di Azure DevOps Server 2022 Update 1

  • Articolo

| Requisiti di sistema della community | degli sviluppatori e condizioni | di licenza di compatibilità | DevOps Blog | SHA-256 Hash |

In questo articolo sono disponibili informazioni sulla versione più recente per Azure DevOps Server.

Per altre informazioni sull'installazione o l'aggiornamento di una distribuzione di Azure DevOps Server, vedere Requisiti del server Azure DevOps.

Per scaricare i prodotti Azure DevOps Server, visitare la pagina download di Azure DevOps Server.

L'aggiornamento diretto ad Azure DevOps Server 2022 Update 1 è supportato da Azure DevOps Server 2019 o Team Foundation Server 2015 o versione successiva. Se la distribuzione di TFS si trova in TFS 2013 o versioni precedenti, è necessario eseguire alcuni passaggi provvisori prima di eseguire l'aggiornamento ad Azure DevOps Server 2022. Per altre informazioni, vedere la pagina Installa.

Data di rilascio di Azure DevOps Server 2022 Update 1 Patch 4: 11 giugno 2024

file Hash SHA-256
devops2022.1patch4.exe 29012B79569F042E2ED4518CE7216CA521F9435CCD80295B71F734AA60FCD03F

È stata rilasciata la patch 4 per Azure DevOps Server 2022 Update 1 che include una correzione per quanto segue.

  • È stato risolto un problema relativo a wiki ed elementi di lavoro in cui i risultati della ricerca non erano disponibili per i progetti che avevano il nome "I" turco per le impostazioni locali turche.

Data di rilascio di Azure DevOps Server 2022 Update 1 Patch 3: 12 marzo 2024

file Hash SHA-256
devops2022.1patch3.exe E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911

È stata rilasciata la patch 3 per Azure DevOps Server 2022 Update 1 che include correzioni per quanto segue.

  • È stato risolto un problema a causa del quale il server proxy smetteva di funzionare dopo l'installazione della patch 2.
  • È stato risolto un problema di rendering nella pagina dei dettagli dell'estensione che interessava le lingue che non erano l'inglese.

Data di rilascio di Azure DevOps Server 2022 Update 1 Patch 2: 13 febbraio 2024

file Hash SHA-256
devops2022.1patch2.exe 59B3191E86DB787F91FD196554DE580CA97F06BA9CCB1D747D41A2317A5441

È stata rilasciata la patch 2 per Azure DevOps Server 2022 Update 1 che include correzioni per quanto segue.

  • Correzione del problema di rendering della pagina dei dettagli nell'estensione di ricerca.
  • Correzione di un bug per cui lo spazio su disco usato dalla cartella della cache proxy è stato calcolato in modo non corretto e la cartella non è stata pulita correttamente.
  • CVE-2024-20667: vulnerabilità di esecuzione remota del codice di Azure DevOps Server.

Data di rilascio di Azure DevOps Server 2022 Update 1 Patch 1: 12 dicembre 2023

file Hash SHA-256
devops2022.1patch1.exe 9D0FDCCD1F20461E586689B756E600CC16424018A377042F7DC3A6EEF096FB6

È stata rilasciata la patch 1 per Azure DevOps Server 2022 Update 1 che include correzioni per quanto segue.

  • Impedire l'impostazione requested for durante l'accodamento di un'esecuzione della pipeline.

Data di rilascio dell'aggiornamento 1 di Azure DevOps Server 2022: 28 novembre 2023

Nota

Esistono due problemi noti con questa versione:

  1. La versione dell'agente non viene aggiornata dopo l'aggiornamento ad Azure DevOps Server 2022.1 e l'uso dell'agente di aggiornamento nella configurazione del pool di agenti. Microsoft sta attualmente lavorando a una patch per risolvere questo problema e condividerà gli aggiornamenti nella community degli sviluppatori durante l'avanzamento. Nel frattempo, è possibile trovare una soluzione alternativa per questo problema in questo ticket della community degli sviluppatori.
  2. Compatibilità di Maven 3.9.x. Maven 3.9.x ha introdotto modifiche di rilievo con Azure Artifacts aggiornando il trasporto del resolver Maven predefinito in HTTP nativo da Wagon. Ciò causa problemi di autenticazione 401 per i clienti che usano http anziché https. Per altre informazioni su questo problema , vedere qui. Come soluzione alternativa, è possibile continuare a usare Maven 3.9.x con la proprietà -Dmaven.resolver.transport=wagon. Questa modifica impone a Maven di usare il trasporto resolver wagon. Per altri dettagli, vedere la documentazione qui .

Azure DevOps Server 2022.1 è un rollup delle correzioni di bug. Include tutte le funzionalità di Azure DevOps Server 2022.1 RC2 rilasciate in precedenza.

Nota

Si è verificato un problema noto con la compatibilità maven 3.9.x. Maven 3.9.x ha introdotto modifiche di rilievo con Azure Artifacts aggiornando il trasporto del resolver Maven predefinito in HTTP nativo da Wagon. Ciò causa problemi di autenticazione 401 per i clienti che usano http anziché https. Per altre informazioni su questo problema , vedere qui.

Come soluzione alternativa, è possibile continuare a usare Maven 3.9.x con la proprietà -Dmaven.resolver.transport=wagon. Questa modifica impone a Maven di usare il trasporto resolver wagon. Per altri dettagli, vedere la documentazione qui .

Data di rilascio di Azure DevOps Server 2022 Update 1 RC2: 31 ottobre 2023

Azure DevOps Server 2022.1 RC2 è un rollup di correzioni di bug. Include tutte le funzionalità di Azure DevOps Server 2022.1 RC1 rilasciate in precedenza.

Nota

Si è verificato un problema noto con la compatibilità maven 3.9.x. Maven 3.9.x ha introdotto modifiche di rilievo con Azure Artifacts aggiornando il trasporto del resolver Maven predefinito in HTTP nativo da Wagon. Ciò causa problemi di autenticazione 401 per i clienti che usano http anziché https. Per altre informazioni su questo problema , vedere qui.

Come soluzione alternativa, è possibile continuare a usare Maven 3.9.x con la proprietà -Dmaven.resolver.transport=wagon. Questa modifica impone a Maven di usare il trasporto resolver wagon. Per altri dettagli, vedere la documentazione qui .

La versione seguente è stata risolta:

  • È stato risolto un problema nei feed locali in cui le voci upstream non risolvevano le modifiche al nome visualizzato.
  • Si è verificato un errore imprevisto durante il passaggio di schede da Codice a un'altra scheda nella pagina Di ricerca.
  • Errore durante la creazione di un nuovo tipo di elemento di lavoro con Ideogrammi unificati cinesi, giapponesi e coreani (CJK). Un punto interrogativo è stato visualizzato nel log RAW al check-in controllato quando il nome del progetto team o i file includevano CJK.
  • È stato risolto un problema durante l'installazione della ricerca in cui la macchina virtuale Java (JVM) non poteva allocare memoria sufficiente al processo di ricerca elastica. Il widget di configurazione della ricerca userà ora Java Development Kit (JDK) in bundle con Ricerca elastica e quindi rimuove la dipendenza da qualsiasi JRE (Java Runtime Environment) preinstallato nel server di destinazione.

Data di rilascio di Azure DevOps Server 2022 Update 1 RC1: 19 settembre 2023

Azure DevOps Server 2022.1 RC1 include molte nuove funzionalità. Tra le caratteristiche principali:

È anche possibile passare a singole sezioni per visualizzare tutte le nuove funzionalità per ogni servizio:

Generali

Tutte le API REST pubbliche supportano ambiti PAT granulari

In precedenza, una serie di API REST di Azure DevOps documentate pubblicamente non erano associate agli ambiti (ad esempio, alla lettura degli elementi di lavoro) che hanno portato i clienti a usare ambiti completi per usare queste API tramite meccanismi di autenticazione non interattivi, ad esempio token di accesso personale (PAT). L'uso di un token di accesso personale con ambito completo aumenta il rischio quando possono atterrare nelle mani di un utente malintenzionato. Questo è uno dei motivi principali per cui molti dei nostri clienti non hanno sfruttato appieno i criteri del piano di controllo per limitare l'utilizzo e il comportamento del pat.

A questo punto, tutte le API REST di Azure DevOps pubbliche sono ora associate a e supportano un ambito pat granulare. Se attualmente si usa un token di accesso personale con ambito completo per l'autenticazione a una delle API REST di Azure DevOps pubbliche, valutare la possibilità di eseguire la migrazione a un token di accesso personale con l'ambito specifico accettato dall'API per evitare l'accesso non necessario. Gli ambiti PAT granulari supportati per una determinata API REST sono disponibili nella sezione Sicurezza delle pagine della documentazione. Inoltre, qui è disponibile una tabella di ambiti.

Le estensioni devono visualizzare i relativi ambiti

Quando si installano le estensioni nella raccolta di Azure DevOps, è possibile esaminare le autorizzazioni necessarie per l'estensione durante l'installazione. Tuttavia, una volta installate, le autorizzazioni di estensione non sono visibili nelle impostazioni dell'estensione. Ciò ha rappresentato una sfida per gli amministratori che devono eseguire una revisione periodica delle estensioni installate. A questo punto, sono state aggiunte le autorizzazioni di estensione alle impostazioni dell'estensione che consentono di esaminare e prendere una decisione informata su se mantenerle o meno.

Creare token di accesso personali per la distribuzione in Marketplace

Boards

Ultima colonna Accessibile nella pagina Piani di recapito

La pagina della directory Piani di recapito fornisce un elenco dei piani definiti per il progetto. È possibile ordinare in base a: Nome, Creato da, Descrizione, Ultimo configurato o Preferiti. Con questo aggiornamento è stata aggiunta una colonna Ultimo accesso alla pagina della directory. Ciò offre visibilità sull'ultima apertura di un piano di recapito e sull'analisi. Di conseguenza, è facile identificare i piani che non vengono più usati e possono essere eliminati.

Gif to demo Last Accessed field (Campo ultimo accesso alla demo) nella pagina Piani di recapito.

Visualizzare tutte le dipendenze dai piani di recapito

I piani di recapito hanno sempre fornito la possibilità di visualizzare le dipendenze tra gli elementi di lavoro. È possibile visualizzare le righe di dipendenza, una alla volta. Con questa versione è stata migliorata l'esperienza consentendo di visualizzare tutte le righe delle dipendenze in tutti gli elementi di lavoro sullo schermo. È sufficiente fare clic sul pulsante di attivazione/disattivazione delle dipendenze in alto a destra del piano di recapito. Fare di nuovo clic su di esso per disattivare le righe.

Gif per visualizzare demo tutte le dipendenze nella pagina Piani di recapito.

Nuovi limiti di revisione degli elementi di lavoro

Negli ultimi anni sono state viste raccolte di progetti con strumenti automatizzati che generano decine di migliaia di revisioni degli elementi di lavoro. In questo modo si verificano problemi con le prestazioni e l'usabilità nel modulo dell'elemento di lavoro e con le API REST per la creazione di report. Per attenuare il problema, è stato implementato un limite di revisione dell'elemento di lavoro di 10.000 al servizio Azure DevOps. Il limite riguarda solo gli aggiornamenti che usano l'API REST, non il modulo dell'elemento di lavoro.

Fare clic qui per altre informazioni sul limite di revisione e su come gestirlo negli strumenti automatizzati.

Aumentare il limite del team di Piani di recapito da 15 a 20

I piani di recapito consentono di visualizzare più backlog e più team nella raccolta di progetti. In precedenza, è possibile visualizzare 15 backlog del team, tra cui una combinazione di backlog e team di progetti diversi. Con questa versione è stato aumentato il limite massimo da 15 a 20.

È stato risolto un bug nell'API Get dei collegamenti agli elementi di lavoro per la creazione di report per restituire il valore remoteUrl corretto per System.LinkTypes.Remote.Related i tipi di collegamento. Prima di questa correzione, veniva restituito il nome della raccolta di progetti errato e un ID progetto mancante.

Creare un endpoint REST di query temporaneo

Sono state viste diverse istanze degli autori di estensioni che tentano di eseguire query non salvate passando l'istruzione WIQL (Work Item Query Language) tramite la querystring. Questa operazione funziona correttamente, a meno che non si disponga di un'istruzione WIQL di grandi dimensioni che raggiunge i limiti del browser sulla lunghezza della stringa di query. Per risolvere questo problema, è stato creato un nuovo endpoint REST per consentire agli autori di strumenti di generare una query temporanea. L'uso dell'ID dalla risposta per passare tramite querystring elimina questo problema.

Per altre informazioni, vedere la pagina della documentazione dell'API REST query temporanee.

API di eliminazione batch

Attualmente, l'unico modo per rimuovere elementi di lavoro dal Cestino consiste nell'usare questa API REST per eliminarli uno alla volta. Questo può essere un processo lento ed è soggetto a limitazione della frequenza quando si tenta di eseguire qualsiasi tipo di pulizia di massa. In risposta, è stato aggiunto un nuovo endpoint DELL'API REST per eliminare e/o eliminare definitivamente gli elementi di lavoro in batch.

@CurrentIteration macro nei piani di recapito

Con questo aggiornamento è stato aggiunto il supporto per la macro per gli @CurrentIteration stili nei piani di recapito. Questa macro consentirà di ottenere l'iterazione corrente dal contesto del team di ogni riga del piano.

Gif per demo macro CurrentIteration nei piani di recapito.

Logica di ridimensionamento delle schede nei piani di recapito

Non tutti usano la data di destinazione e/o la data di inizio durante il rilevamento delle funzionalità e delle epiche. Alcuni scelgono di usare una combinazione di date e percorso di iterazione. In questa versione è stata migliorata la logica per impostare in modo appropriato le combinazioni di percorso di iterazione e campo data a seconda della modalità di utilizzo.

Ad esempio, se la data di destinazione non viene usata e si ridimensiona la scheda, il nuovo percorso di iterazione viene impostato invece di aggiornare la data di destinazione.

Collegamento gif per la copia demo dei commenti.

Miglioramenti dell'aggiornamento batch

Sono state apportate diverse modifiche alla versione 7.1 dell'API di aggiornamento batch dell'elemento di lavoro. Questi includono miglioramenti minori delle prestazioni e la gestione degli errori parziali. Ciò significa che, se una patch ha esito negativo, ma le altre non lo fanno, le altre verranno completate correttamente.

Fare clic qui per altre informazioni sull'API REST di aggiornamento batch.

API di eliminazione batch

Questo nuovo endpoint DELL'API REST per eliminare e/o eliminare definitivamente gli elementi di lavoro in batch è ora disponibile pubblicamente. Fare clic qui per altre informazioni.

Impedire la modifica dei campi degli elenchi di selezione condivisibili

I campi personalizzati vengono condivisi tra processi. Questo può creare un problema per i campi dell'elenco a discesa perché è possibile consentire agli amministratori del processo di aggiungere o rimuovere valori dal campo. In questo caso, le modifiche influiscono su tale campo su ogni processo che lo usa.

Per risolvere questo problema, è stata aggiunta la possibilità per l'amministratore della raccolta di "bloccare" un campo da modificare. Quando il campo dell'elenco a discesa è bloccato, l'amministratore del processo locale non può modificare i valori di tale elenco a discesa. Possono aggiungere o rimuovere solo il campo dal processo.

Gif per la modifica demo dei campi picklist condivisibili.

Nuova autorizzazione salva commenti

La possibilità di salvare solo i commenti degli elementi di lavoro è stata una richiesta principale nella community degli sviluppatori. Siamo lieti di informare l'utente che questa funzionalità è stata implementata. Per iniziare, esaminiamo lo scenario più comune:

"Voglio impedire ad alcuni utenti di modificare i campi dell'elemento di lavoro, ma consentire loro di contribuire alla discussione."

A tale scopo, è necessario passare a Project Settings > Project Configuration Area Path (Percorso area di configurazione > progetto). Selezionare quindi il percorso di area scelto e fare clic su Sicurezza.

Area Path

Si noti la nuova autorizzazione "Modificare i commenti degli elementi di lavoro in questo nodo". Per impostazione predefinita, l'autorizzazione è impostata su Non impostato. Ciò significa che l'elemento di lavoro si comporta esattamente come in precedenza. Per consentire a un gruppo o agli utenti di salvare i commenti, selezionare tale gruppo/utenti e modificare l'autorizzazione in Consenti.

Nuova autorizzazione

Quando l'utente apre il modulo dell'elemento di lavoro in questo percorso dell'area, sarà in grado di aggiungere commenti, ma non sarà in grado di aggiornare uno degli altri campi.

Modifica demo dei campi elenco a discesa condivisibili.

Speriamo che tu ami questa funzionalità tanto quanto noi. Come sempre, se hai un feedback o suggerimenti, ti preghiamo di comunicarci.

Report interattivi sulle bacheche

I report interattivi, situati nell'hub Boards, sono stati accessibili da diversi anni nella nostra versione ospitata del prodotto. Sostituiscono i grafici cumulativi precedenti diagramma di flusso, velocità e burndown sprint. Con questa versione vengono resi disponibili.

Per visualizzare questi grafici, fare clic sul percorso della scheda Analisi nelle pagine Lavagna Kanban, Backlog e Sprint.

Report interattivi

Repos

Rimozione dell'autorizzazione "Modifica criteri" per l'autore di rami

In precedenza, quando è stato creato un nuovo ramo, è stata concessa l'autorizzazione per modificare i criteri in tale ramo. Con questo aggiornamento il comportamento predefinito viene modificato in modo da non concedere questa autorizzazione, anche se l'impostazione "Gestione autorizzazioni" viene attivata per il repository.

Immagine di gestione delle autorizzazioni.

Sarà necessario concedere l'autorizzazione "Modifica criteri" concessa in modo esplicito (manualmente o tramite l'API REST) tramite l'ereditarietà delle autorizzazioni di sicurezza o tramite l'appartenenza a un gruppo.

Pipeline

Il progetto corrente è impostato come ambito predefinito per il token di accesso alla compilazione nelle pipeline classiche

Azure Pipelines usa i token di accesso ai processi per accedere ad altre risorse in Azure DevOps in fase di esecuzione. Un token di accesso del processo è un token di sicurezza generato dinamicamente da Azure Pipelines per ogni processo in fase di esecuzione. In precedenza, durante la creazione di una nuova pipeline classica, il valore predefinito per il token di accesso è stato impostato su Raccolta progetti. Con questo aggiornamento, l'ambito di autorizzazione del processo viene impostato sul progetto corrente come predefinito durante la creazione di una nuova pipeline classica.

Per altre informazioni sui token di accesso ai processi, vedere la documentazione relativa a repository, artefatti e altre risorse di Access.

Modificare l'ambito predefinito dei token di accesso nelle pipeline di compilazione classiche

Per migliorare la sicurezza delle pipeline di compilazione classiche, quando ne crea uno nuovo, l'ambito di autorizzazione del processo di compilazione sarà Project, per impostazione predefinita. Fino ad ora, era raccolta di progetti. Altre informazioni sui token di accesso ai processi. Questa modifica non influisce sulle pipeline esistenti. Influisce solo sulle nuove pipeline di compilazione classiche create da questo punto in poi.

Supporto di Azure Pipelines per Le versioni di San Diego, Tokyo e Utah di ServiceNow

Azure Pipelines ha un'integrazione esistente con ServiceNow. L'integrazione si basa su un'app in ServiceNow e un'estensione in Azure DevOps. L'app è stata aggiornata per lavorare con le versioni di San Diego, Tokyo e Utah di ServiceNow. Per assicurarsi che questa integrazione funzioni, eseguire l'aggiornamento alla nuova versione dell'app (4.215.2) dall'archivio ServiceNow.

Per altre informazioni, vedere la documentazione sull'integrazione con ServiceNow Change Management.

Usare gli URL proxy per l'integrazione di GitHub Enterprise

Azure Pipelines si integra con i server GitHub Enterprise locali per eseguire l'integrazione continua e le compilazioni pull. In alcuni casi, GitHub Enterprise Server si trova dietro un firewall e richiede che il traffico venga instradato attraverso un server proxy. Per supportare questo scenario, le connessioni al servizio GitHub Enterprise Server in Azure DevOps consentono di configurare un URL proxy. In precedenza, non tutto il traffico proveniente da Azure DevOps veniva instradato tramite questo URL proxy. Con questo aggiornamento si garantisce che venga instradato il traffico seguente da Azure Pipelines per passare attraverso l'URL del proxy:

  • Ottenere rami
  • Ottenere informazioni sulla richiesta pull
  • Stato della compilazione del report

Le connessioni al servizio Registro Container possono ora usare identità gestite di Azure

È possibile usare un'identità gestita assegnata dal sistema durante la creazione di connessioni al servizio Registro Docker per Registro Azure Container. In questo modo è possibile accedere alle Registro Azure Container usando un'identità gestita associata a un agente di Azure Pipelines self-hosted, eliminando la necessità di gestire le credenziali.

Nuova connessione al servizio registro Docker per le modifiche alle approvazioni

Nota

L'identità gestita usata per accedere a Registro Azure Container richiederà l'assegnazione di Controllo di accesso (RBAC) appropriata, ad esempio il ruolo AcrPull o AcrPush.

Token automatici creati per la connessione al servizio Kubernetes

A partire da Kubernetes 1.24, i token non sono più stati creati automaticamente durante la creazione di una nuova connessione al servizio Kubernetes. Questa funzionalità è stata aggiunta di nuovo. È tuttavia consigliabile usare la connessione al servizio Azure Kubernetes per accedere al servizio Azure Kubernetes. Per altre informazioni, vedere il post di blog Relativo alle connessioni al servizio Azure Kubernetes per i clienti che usano le attività di Kubernetes.

Le attività kubernetes ora supportano kubelogin

Sono state aggiornate le attività di KuberentesManifest@1, HelmDeploy@0, Kubernetes@1 e AzureFunctionOnKubernetes@1 per supportare kubelogin. In questo modo, è possibile specificare come destinazione servizio Azure Kubernetes configurata con l'integrazione di Azure Active Directory.

Kubelogin non è preinstallato nelle immagini ospitate. Per assicurarsi che le attività indicate in precedenza usino kubelogin, installarle inserendo l'attività KubeloginInstaller@0 prima dell'attività che dipende da essa:

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

Miglioramenti dell'esperienza alle autorizzazioni della pipeline

È stata migliorata l'esperienza relativa alla gestione delle autorizzazioni della pipeline per fare in modo che il sistema delle autorizzazioni ricordi se una pipeline aveva usato in precedenza una risorsa protetta, ad esempio una connessione al servizio.

In passato, se è stato selezionato "Concedere l'autorizzazione di accesso a tutte le pipeline" quando è stata creata una risorsa protetta, ma è stato limitato l'accesso alla risorsa, la pipeline ha richiesto una nuova autorizzazione per usare la risorsa. Questo comportamento non era coerente con l'apertura e la chiusura successive dell'accesso alla risorsa, in cui non era necessaria una nuova autorizzazione. Questo problema è stato risolto.

Nuovo ambito pat per la gestione dell'autorizzazione e delle approvazioni della pipeline e dei controlli

Per limitare i danni causati dalla perdita di un token PAT, è stato aggiunto un nuovo ambito pat denominato Pipeline Resources. È possibile usare questo ambito pat quando si gestisce l'autorizzazione della pipeline usando una risorsa protetta, ad esempio una connessione al servizio o per gestire le approvazioni e verificare la presenza di tale risorsa.

Screenshot che mostra gli aggiornamenti dell'API REST delle pipeline.

Le chiamate API REST seguenti supportano il nuovo ambito pat come indicato di seguito:

Limitare l'apertura di risorse protette agli amministratori delle risorse

Per migliorare la sicurezza delle risorse fondamentali per la possibilità di compilare e distribuire in modo sicuro le applicazioni, Azure Pipelines richiede ora un ruolo di amministratore di tipo risorsa quando si apre l'accesso a una risorsa a tutte le pipeline.

Ad esempio, è necessario un ruolo amministratore delle connessioni al servizio generale per consentire a qualsiasi pipeline di usare una connessione al servizio. Questa restrizione si applica quando si crea una risorsa protetta o quando si modifica la configurazione di sicurezza.

Inoltre, quando si crea una connessione al servizio e non si dispone di diritti sufficienti, l'opzione Concedi l'autorizzazione di accesso a tutte le pipeline è disabilitata.

Connessioni al servizio Inoltre, quando si tenta di aprire l'accesso a una risorsa esistente e non si dispone di diritti sufficienti, si otterrà un utente non autorizzato ad aprire l'accesso per questo messaggio di risorsa .

Autorizzazioni pipeline

Miglioramenti della sicurezza dell'API REST delle pipeline

La maggior parte delle API REST in Azure DevOps usa token PAT con ambito. Tuttavia, alcuni di essi richiedono token PAT con ambito completo. In altre parole, è necessario creare un token pat selezionando "Accesso completo" per usare alcune di queste API. Tali token rappresentano un rischio per la sicurezza perché possono essere usati per chiamare qualsiasi API REST. Sono stati apportati miglioramenti in Azure DevOps per rimuovere la necessità di token con ambito completo incorporando ogni API REST in un ambito specifico. Come parte di questa operazione, l'API REST per aggiornare le autorizzazioni della pipeline per una risorsa richiede ora un ambito specifico. L'ambito dipende dal tipo di risorsa autorizzata per l'uso:

  • Code (read, write, and manage) per le risorse di tipo repository
  • Agent Pools (read, manage) o Environment (read, manage) per le risorse di tipo queue e agentpool
  • Secure Files (read, create, and manage) per le risorse di tipo securefile
  • Variable Groups (read, create and manage) per le risorse di tipo variablegroup
  • Service Endpoints (read, query and manage) per le risorse di tipo endpoint
  • Environment (read, manage) per le risorse di tipo environment

Per modificare in blocco le autorizzazioni delle pipeline, è comunque necessario un token PAT con ambito completo. Per altre informazioni sull'aggiornamento delle autorizzazioni della pipeline per le risorse, vedere la documentazione Relativa alle autorizzazioni della pipeline - Aggiornare le autorizzazioni della pipeline per le risorse .

Gestione degli accessi con granularità fine per i pool di agenti

I pool di agenti consentono di specificare e gestire i computer in cui vengono eseguite le pipeline.

In precedenza, se è stato usato un pool di agenti personalizzato, la gestione delle pipeline a cui è possibile accedere è stata eseguita con granularità grossolana. È possibile consentire a tutte le pipeline di usarlo oppure richiedere a ogni pipeline di richiedere l'autorizzazione. Sfortunatamente, dopo aver concesso un'autorizzazione di accesso alla pipeline a un pool di agenti, non è stato possibile revocarlo usando l'interfaccia utente delle pipeline.

Azure Pipelines offre ora una gestione degli accessi con granularità fine per i pool di agenti. L'esperienza è simile a quella per la gestione delle autorizzazioni della pipeline per le connessioni al servizio.

Pool di agenti FabrikamFiber per le modifiche alle approvazioni

Impedire di concedere a tutte le pipeline l'accesso alle risorse protette

Quando si crea una risorsa protetta, ad esempio una connessione al servizio o un ambiente, è possibile selezionare la casella di controllo Concedi autorizzazione di accesso a tutte le pipeline . Fino ad ora, questa opzione è stata selezionata per impostazione predefinita.

Anche se ciò rende più semplice per le pipeline l'uso di nuove risorse protette, il contrario è che favorisce accidentalmente la concessione di troppe pipeline il diritto di accedere alla risorsa.

Per alzare di livello una scelta sicura per impostazione predefinita, Azure DevOps lascia ora deselezionata la casella di controllo.

Concedere l'autorizzazione di accesso a tutte le pipeline è disattivata per impostazione predefinita

Possibilità di disabilitare la maschera per i segreti brevi

Azure Pipelines maschera i segreti nei log. I segreti possono essere variabili contrassegnate come segrete, variabili di gruppi di variabili collegati ad Azure Key Vault o elementi di una connessione al servizio contrassegnata come segreto dal provider di connessione del servizio.

Tutte le occorrenze del valore del segreto vengono mascherate. Mascherare i segreti brevi, ad esempio '', '1', 'Dev2' semplifica l'indovinare i valori, ad esempio in una data: 'Jan 3, 202***'
Ora è chiaro che '3' è un segreto. In questi casi potresti preferire di non mascherare completamente il segreto. Se non è possibile contrassegnare il valore come segreto (ad esempio, il valore viene ricavato da Key Vault), è possibile impostare la AZP_IGNORE_SECRETS_SHORTER_THAN manopola su un valore massimo di 4.

Attività di download di Node Runner

Quando si adottano versioni dell'agente che escludono lo strumento di esecuzione attività del nodo 6, potrebbe essere necessario eseguire occasionalmente attività che non sono state aggiornate per usare uno strumento di esecuzione del nodo più recente. Per questo scenario viene fornito un metodo per continuare a usare le attività dipendenti dagli strumenti di esecuzione end-of-life di Node, vedere il post di blog sulle linee guida per Node Runner.

L'attività seguente è un metodo per installare lo strumento di esecuzione di Node 6 just-in-time, in modo che un'attività precedente possa comunque essere eseguita:

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 6

Convalida aggiornata dello strumento di esecuzione dei nodi TFX

Gli autori di attività usano lo strumento di creazione pacchetti di estensioni (TFX) per pubblicare le estensioni. TFX è stato aggiornato per eseguire le convalide nelle versioni di Node Runner, vedere il post di blog sulle linee guida per Node Runner.

Le estensioni che contengono attività che usano lo strumento di esecuzione del nodo 6 visualizzeranno questo avviso:

Task <TaskName> is dependent on a task runner that is end-of-life and will be removed in the future. Authors should review Node upgrade guidance: https://aka.ms/node-runner-guidance.

Istruzioni per la preinstallazione manuale di Node 6 sugli agenti della pipeline

Se si usa il feed dell'agentepipeline-, il nodo 6 non è incluso nell'agente. In alcuni casi, in cui un'attività marketplace dipende ancora da Node 6 e l'agente non è in grado di usare l'attività NodeTaskRunnerInstaller (ad esempio a causa di restrizioni di connettività), sarà necessario pre-installare Node 6 in modo indipendente. A questo scopo, vedere le istruzioni su come installare manualmente lo strumento di esecuzione di Node 6.

Log delle modifiche delle attività della pipeline

Ora vengono pubblicate le modifiche apportate alle attività della pipeline in questo changelog. Contiene l'elenco completo delle modifiche apportate alle attività pipeline predefinite. Sono state pubblicate in modo retroattivo le modifiche precedenti, quindi il log delle modifiche fornisce un record cronologico degli aggiornamenti delle attività.

Le attività di rilascio usano l'API Microsoft Graph

Le attività di rilascio sono state aggiornate per l'uso dell'API Microsoft Graph. In questo modo viene rimosso l'utilizzo dell'API Graph di AAD dalle attività.

Miglioramento delle prestazioni delle attività di Windows PowerShell

È possibile usare le attività per definire l'automazione in una pipeline. Una di queste attività è l'attività PowerShell@2 di utilità che consente di eseguire script di PowerShell nella pipeline. Per usare lo script di PowerShell per definire come destinazione un ambiente Azure, è possibile usare l'attività AzurePowerShell@5 . Alcuni comandi di PowerShell che possono stampare gli aggiornamenti dello stato di avanzamento, ad esempio Invoke-WebRequest, ora vengono eseguiti più velocemente. Il miglioramento è più significativo se si dispone di molti di questi comandi nello script o quando sono a esecuzione prolungata. Con questo aggiornamento, la progressPreference proprietà delle PowerShell@2 attività e AzurePowerShell@5 è ora impostata su SilentlyContinue per impostazione predefinita.

Agente pipeline v3 in .NET 6

L'agente pipeline è stato aggiornato per usare .NET 3.1 Core a .NET 6 come runtime. Questo introduce il supporto nativo per Apple Silicon e Windows Arm64.

L'uso di .NET 6 influisce sui requisiti di sistema per l'agente. In particolare, rilasciamo il supporto per i sistemi operativi seguenti: CentOS 6, Fedora 29-33, Linux Mint 17-18, Red Hat Enterprise Linux 6. Vedere la documentazione di Agent software versione 3.

Questo script può essere usato per identificare le pipeline che usano agenti con sistemi operativi non supportati.

Importante

Tenere presente che gli agenti in esecuzione in uno dei sistemi operativi precedenti non verranno più aggiornati o non riusciranno dopo l'implementazione dell'agente basato su .NET 6.

Specificare la versione dell'agente nell'estensione macchina virtuale dell'agente

Le macchine virtuali di Azure possono essere incluse nei gruppi di distribuzione usando un'estensione macchina virtuale. L'estensione macchina virtuale è stata aggiornata per specificare facoltativamente la versione dell'agente desiderata da installare:

    "properties": {
      ...
      "settings": {
        ...
        "AgentMajorVersion": "auto|2|3",
        ...
      },
      ...
     }

Nuovi interruttori per controllare la creazione di pipeline classiche

Azure DevOps consente ora di assicurarsi che la raccolta di progetti usi solo pipeline YAML, disabilitando la creazione di pipeline di compilazione classiche, pipeline di versione classica, gruppi di attività e gruppi di distribuzione. Le pipeline classiche esistenti continueranno a essere eseguite e sarà possibile modificarle, ma non sarà possibile crearne di nuove.

Azure DevOps consente ora di assicurarsi che l'organizzazione usi solo pipeline YAML, disabilitando la creazione di pipeline di compilazione classiche, pipeline di versione classica, gruppi di attività e gruppi di distribuzione. Le pipeline classiche esistenti continueranno a essere eseguite e sarà possibile modificarle, ma non sarà possibile crearne di nuove.

È possibile disabilitare la creazione di pipeline classiche a livello di raccolta di progetti o a livello di progetto attivando gli interruttori corrispondenti. Gli interruttori sono disponibili in Project/Project Settings - Pipelines - Settings (Impostazioni progetto -> Pipeline -> Impostazioni). Esistono due interruttori: uno per le pipeline di compilazione classiche e uno per le pipeline di versione classica, i gruppi di distribuzione e i gruppi di attività.

Disabilitare la creazione di pipeline classiche

Lo stato di attivazione/disattivazione è disattivato per impostazione predefinita e saranno necessari diritti di amministratore per modificare lo stato. Se l'interruttore è attivato a livello di organizzazione, la disabilitazione viene applicata per tutti i progetti. In caso contrario, ogni progetto è libero di scegliere se applicare o meno la disabilitazione.

Quando si disabilita la creazione di pipeline classiche, le API REST correlate alla creazione di pipeline classiche, gruppi di attività e gruppi di distribuzione avranno esito negativo. Le API REST che creano pipeline YAML funzioneranno.

Aggiornamenti all'evento hook del servizio "Stato di esecuzione modificata"

Gli hook del servizio consentono di eseguire attività in altri servizi quando si verificano eventi nel progetto in Azure DevOps, lo stato della fase di esecuzione è stato modificato è uno di questi eventi. L'evento Run stage state changed deve contenere informazioni sull'esecuzione, incluso il nome della pipeline. In precedenza, includeva solo informazioni sull'ID e sul nome dell'esecuzione. Con questo aggiornamento sono state apportate modifiche all'evento in modo da includere informazioni mancanti.

Disabilitare la visualizzazione dell'ultimo messaggio di commit per un'esecuzione della pipeline

In precedenza, l'interfaccia utente pipeline usata per visualizzare l'ultimo messaggio di commit durante la visualizzazione dell'esecuzione di una pipeline.

Esempio di ultimo messaggio di commit

Questo messaggio può generare confusione, ad esempio quando il codice della pipeline YAML si trova in un repository diverso da quello che contiene il codice che sta compilando. Il feedback ricevuto dalla community degli sviluppatori richiede un modo per abilitare o disabilitare l'aggiunta del messaggio di commit più recente al titolo di ogni esecuzione della pipeline.

Con questo aggiornamento è stata aggiunta una nuova proprietà YAML denominata , che appendCommitMessageToRunNameconsente di eseguire esattamente questa operazione. Per impostazione predefinita, la proprietà è impostata su true. Quando si imposta su false, l'esecuzione della pipeline visualizzerà solo .BuildNumber

Esempio di esecuzione della pipeline con numero di build

Esempio di esecuzione della pipeline con l'ultimo messaggio di commit

Aumento dei limiti di Azure Pipeline per allinearsi alle dimensioni massime del modello di Azure Resource Manager (ARM) di 4 MB.

È possibile usare l'attività Distribuzione modelli di Azure Resource Manager per creare l'infrastruttura di Azure. In risposta ai commenti e suggerimenti, è stato aumentato il limite di integrazione di Azure Pipelines da 2 MB a 4 MB. Questa operazione verrà allineata alle dimensioni massime dei modelli arm di 4 MB che risolve i vincoli di dimensione durante l'integrazione di modelli di grandi dimensioni.

Icona panoramica dello stato dell'esecuzione della pipeline

Con questa versione, è più semplice conoscere lo stato complessivo di un'esecuzione della pipeline.

Per le pipeline YAML che hanno molte fasi, è difficile conoscere lo stato di un'esecuzione della pipeline, ovvero è ancora in esecuzione o è stata completata. E se è terminato, qual è lo stato complessivo: esito positivo, non riuscito o annullato. Questo problema è stato risolto aggiungendo un'icona di panoramica dello stato di esecuzione.

Icona panoramica dello stato dell'esecuzione della pipeline

Pannello laterale Fasi pipeline

Le pipeline YAML possono avere decine di fasi e non tutte si adatteranno sullo schermo. Anche se l'icona di panoramica dell'esecuzione della pipeline indica lo stato complessivo dell'esecuzione, è ancora difficile sapere quale fase non è riuscita o quale fase è ancora in esecuzione, ad esempio.

In questa versione è stato aggiunto un pannello laterale delle fasi della pipeline che consente di visualizzare rapidamente lo stato di tutte le fasi. È quindi possibile fare clic su una fase e accedere direttamente ai relativi log.

Aggiornare le pipeline

Aggiornamenti dell'interfaccia utente di Pipelines

Cercare le fasi nel pannello laterale

Abbiamo reso più semplice trovare le fasi che stai cercando nel pannello laterale delle fasi. È ora possibile filtrare rapidamente le fasi in base al relativo stato, ad esempio le fasi di esecuzione o quelle che richiedono l'intervento manuale. È anche possibile cercare le fasi in base al nome.

Aggiornare le pipeline AZ

Fasi azioni rapide

La schermata Esecuzioni di una pipeline consente di accedere rapidamente a tutte le fasi di esecuzione. In questa versione è stato aggiunto un pannello fasi da cui è possibile eseguire azioni per ogni fase. Ad esempio, è possibile rieseguire facilmente processi non riusciti o rieseguire l'intera fase. Il pannello è disponibile quando non tutte le fasi rientrano nell'interfaccia utente, come si può vedere nello screenshot seguente.

Screenshot della pipeline con troppe fasi. Quando si fa clic sul segno '+' nella colonna fasi, viene visualizzato il pannello fasi e quindi è possibile eseguire azioni di fase.

Screenshot del pannello fasi.

Controlla i miglioramenti dell'esperienza utente

Stiamo semplificando la lettura dei log dei controlli. I log di controllo forniscono informazioni critiche per il successo della distribuzione. Possono indicare se si è dimenticato di chiudere un ticket dell'elemento di lavoro o se è necessario aggiornare un ticket in ServiceNow. In precedenza, sapendo che un controllo fornito tali informazioni critiche era difficile.

La pagina dei dettagli dell'esecuzione della pipeline mostra ora il log di controllo più recente. Questo è solo per i controlli che seguono l'utilizzo consigliato.

Immagine che mostra il log di controllo più recente.Per evitare approvazioni approvate erroneamente, Azure DevOps mostra le istruzioni per i responsabili approvazione nel pannello Approvazioni e controlli sul lato della pagina dei dettagli dell'esecuzione della pipeline.

In attesa dell'immagine di revisione della pipeline.

Disabilitare un controllo

Sono stati eseguiti controlli di debug meno noiosi. In alcuni casi, un controllo richiama la funzione di Azure o richiama l'API REST non funziona correttamente ed è necessario correggerlo. In precedenza, è stato necessario eliminare tali controlli, per evitare che blocchino erroneamente una distribuzione. Dopo aver corretto il controllo, è necessario aggiungerlo nuovamente e configurarlo correttamente, assicurandosi che tutte le intestazioni necessarie siano impostate o che i parametri di query siano corretti. Questo è noioso.

È ora possibile disabilitare un controllo. Il controllo disabilitato non verrà eseguito nelle valutazioni successive della suite di controllo.

Disabilitare un'immagine di controllo. Dopo aver corretto il controllo errato, è sufficiente abilitarlo.

Abilitare un'immagine di controllo.

Risorse usate e parametri del modello nell'API REST Esecuzioni di pipeline

L'API REST Pipelines Runs restituisce ora più tipi di artefatti usati da un'esecuzione della pipeline e i parametri usati per attivare l'esecuzione. È stata migliorata l'API per restituire le container risorse e pipeline e i parametri del modello usati in un'esecuzione della pipeline. È ora possibile, ad esempio, scrivere controlli di conformità che valutano i repository, i contenitori e altre esecuzioni di pipeline usate da una pipeline.

Di seguito è riportato un esempio del nuovo corpo della risposta.

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

Supporto del modello di disponibilità generale nell'editor YAML

I modelli sono una funzionalità comunemente usata nelle pipeline YAML. Sono un modo semplice per condividere frammenti di pipeline. Sono anche un meccanismo potente per verificare o applicare la sicurezza e la governance tramite la pipeline.

Azure Pipelines supporta un editor YAML, che può essere utile quando si modifica la pipeline. Tuttavia, l'editor non supportava i modelli fino ad ora. Gli autori di pipeline YAML non hanno potuto ottenere assistenza tramite intelliSense quando si usa un modello. Gli autori di modelli non possono usare l'editor YAML. In questa versione viene aggiunto il supporto per i modelli nell'editor YAML.

Quando si modifica il file YAML di Azure Pipelines principale, è possibile includere o estendere un modello. Quando si digita il nome del modello, verrà richiesto di convalidare il modello. Dopo la convalida, l'editor YAML riconosce lo schema del modello, inclusi i parametri di input.

Aggiornamenti dell'API REST delle pipeline

Dopo la convalida, è possibile scegliere di passare al modello. Sarà possibile apportare modifiche al modello usando tutte le funzionalità dell'editor YAML.

Esistono limitazioni note:

  • Se il modello ha parametri obbligatori che non vengono forniti come input nel file YAML principale, la convalida non riesce e richiede di fornire tali input. In un'esperienza ideale, la convalida non deve essere bloccata e dovrebbe essere possibile compilare i parametri di input usando intelliSense.
  • Non è possibile creare un nuovo modello dall'editor. È possibile usare o modificare solo i modelli esistenti.

Nuova variabile di sistema predefinita

È stata introdotta una nuova variabile di sistema predefinita denominata Build.DefinitionFolderPath, il cui valore è il percorso della cartella di una definizione della pipeline di compilazione. La variabile è disponibile sia nelle pipeline di compilazione YAML che in quella classica.

Ad esempio, se la pipeline è ospitata nella FabrikamFiber\Chat cartella in Azure Pipelines, il valore di Build.DefinitionFolderPath è FabrikamFiber\Chat.

Aggiunta del supporto per la funzione di suddivisione di stringhe nelle espressioni modello YAML

Le pipeline YAML offrono modi pratici per ridurre la duplicazione del codice, ad esempio il ciclo attraverso each il valore di un elenco o di una proprietà di un oggetto.

In alcuni casi, il set di elementi da scorrere viene rappresentato come stringa. Ad esempio, quando l'elenco di ambienti a cui eseguire la distribuzione è definito dalla stringa integration1, integration2.

Durante l'ascolto dei commenti e suggerimenti della community degli sviluppatori, è stata rilevata una funzione stringa split nelle espressioni modello YAML.

È ora possibile split eseguire un'iterazione di una stringa sulle each relative sottostringhe.

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

Espressioni modello nella definizione della risorsa del repository

È stato aggiunto il supporto per le espressioni modello quando si definisce la ref proprietà di una repository risorsa in una pipeline YAML. Questa è stata una funzionalità molto richiesta dalla community degli sviluppatori.

Esistono casi d'uso quando si vuole che la pipeline esestraa rami diversi della stessa risorsa del repository.

Si supponga, ad esempio, di avere una pipeline che compila il proprio repository e, per questo, deve controllare una libreria da un repository di risorse. Si supponga inoltre di voler controllare lo stesso ramo di libreria usato dalla pipeline stessa. Ad esempio, se la pipeline viene eseguita nel main ramo, deve controllare il main ramo del repository di libreria. Se le pipeline vengono eseguite nel dev ramo, è necessario controllare il ramo della dev libreria.

Fino ad oggi, è necessario specificare in modo esplicito il ramo da archiviare e modificare il codice della pipeline ogni volta che il ramo cambia.

A questo punto, è possibile usare espressioni modello per scegliere il ramo di una risorsa del repository. Vedere l'esempio seguente di codice YAML da usare per i rami non principali della pipeline:

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

Quando si esegue la pipeline, è possibile specificare il ramo da controllare per il library repository.

Specificare la versione di un modello da estendere in fase di coda di compilazione

I modelli rappresentano un ottimo modo per ridurre la duplicazione del codice e migliorare la sicurezza delle pipeline.

Un caso d'uso comune consiste nel ospitare i modelli nel proprio repository. In questo modo si riduce l'accoppiamento tra un modello e le pipeline che lo estendono e semplifica l'evoluzione del modello e delle pipeline in modo indipendente.

Si consideri l'esempio seguente, in cui viene usato un modello per monitorare l'esecuzione di un elenco di passaggi. Il codice del modello si trova nel Templates repository.

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

Si supponga di avere una pipeline YAML che estende questo modello, che si trova nel repository FabrikamFiber. Fino ad oggi, non era possibile specificare dinamicamente la ref proprietà della templates risorsa del repository quando si usa il repository come origine modello. Ciò significa che è stato necessario modificare il codice della pipeline se si vuole che la pipeline: estendere un modello da un ramo diverso estende un modello dallo stesso nome di ramo della pipeline, indipendentemente dal ramo in cui è stata eseguita la pipeline

Con l'introduzione delle espressioni modello nella definizione della risorsa del repository, è possibile scrivere la pipeline come segue:

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

In questo modo, la pipeline estenderà il modello nello stesso ramo del ramo in cui viene eseguita la pipeline, in modo da assicurarsi che i rami della pipeline e del modello corrispondano sempre. Ovvero, se si esegue la pipeline in un ramo dev, il modello specificato dal template.yml file nel dev ramo del templates repository verrà esteso.

In alternativa, è possibile scegliere, in fase di compilazione, quale ramo del repository di modelli usare, scrivendo il codice YAML seguente.

parameters:
  - name: branch
    default: main

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ parameters.branch }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: ./build.sh
      - script: ./test.sh

A questo punto, è possibile avere la pipeline nel ramo main estendere un modello da un ramo dev in un'unica esecuzione ed estendere un modello da un ramo main in un'altra esecuzione, senza modificare il codice della pipeline.

Quando si specifica un'espressione modello per la ref proprietà di una risorsa del repository, è possibile usare parameters le variabili predefinite di sistema e di sistema, ma non è possibile usare variabili definite dall'interfaccia utente YAML o Pipelines.

Espressioni modello nella definizione di risorsa contenitore

È stato aggiunto il supporto per le espressioni modello quando si definiscono le endpointproprietà , volumesports, e options di una container risorsa in una pipeline YAML. Questa è stata una funzionalità molto richiesta dalla community degli sviluppatori.

È ora possibile scrivere pipeline YAML come le seguenti.

parameters:
  - name: endpointName    
    default: AzDOACR
    type: string

resources:
  containers:
    - container: linux
      endpoint: ${{ parameters.endpointName }}
      image: fabrikamfiber.azurecr.io/ubuntu:latest

jobs:
- job:
  container: linux
  steps:
  - task: CmdLine@2
    inputs:
      script: 'echo Hello world'

È possibile usare parameters. e variables. nelle espressioni del modello. Per le variabili, è possibile usare solo quelli definiti nel file YAML, ma non quelli definiti nell'interfaccia utente di Pipelines. Se si ridefinisce la variabile, ad esempio usando i comandi di log dell'agente, non avrà alcun effetto.

Miglioramenti delle compilazioni pianificate

È stato risolto un problema che causava il danneggiamento delle informazioni di pianificazione di una pipeline e la pipeline non veniva caricata. Ciò è stato causato, ad esempio, quando il nome del ramo ha superato un determinato numero di caratteri.

Messaggio di errore migliorato quando non è possibile caricare le pipeline

Azure Pipelines offre diversi tipi di trigger per configurare l'avvio della pipeline. Un modo per eseguire una pipeline consiste nell'usare i trigger pianificati. In alcuni casi, le informazioni sull'esecuzione pianificata di una pipeline vengono danneggiate e possono causare un errore di caricamento. In precedenza veniva visualizzato un messaggio di errore fuorviante, sostenendo che la pipeline non è stata trovata. Con questo aggiornamento, questo problema è stato risolto e viene restituito un messaggio di errore informativo. In futuro si riceverà un messaggio simile al seguente: i dati di pianificazione della compilazione sono danneggiati se non è possibile caricare una pipeline.

Non sincronizzare i tag durante il recupero di un repository Git

L'attività di estrazione usa --tags l'opzione per recuperare il contenuto di un repository Git. In questo modo il server recupera tutti i tag e tutti gli oggetti a cui puntano tali tag. Questo aumenta il tempo necessario per eseguire l'attività in una pipeline, in particolare se si dispone di un repository di grandi dimensioni con un numero di tag. Inoltre, l'attività di estrazione sincronizza i tag anche quando si abilita l'opzione di recupero superficiale, in tal modo eventualmente sconfiggendone lo scopo. Per ridurre la quantità di dati recuperati o estratti da un repository Git, è stata aggiunta una nuova opzione all'attività per controllare il comportamento dei tag di sincronizzazione. Questa opzione è disponibile sia nelle pipeline classiche che nelle pipeline YAML.

Questo comportamento può essere controllato dal file YAML o dall'interfaccia utente.

Per rifiutare esplicitamente la sincronizzazione dei tag tramite il file YAML, aggiungere al fetchTags: false passaggio di estrazione. Quando l'opzione fetchTags non è specificata, è uguale a se fetchTags: true viene usata.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Se si vuole modificare il comportamento delle pipeline YAML esistenti, potrebbe essere più utile impostare questa opzione nell'interfaccia utente anziché aggiornare il file YAML. Per passare all'interfaccia utente, aprire l'editor YAML per la pipeline, selezionare Trigger, quindi Elabora e quindi passaggio Checkout.

Se si specifica questa impostazione sia nel file YAML che nell'interfaccia utente, il valore specificato nel file YAML ha la precedenza.

Per tutte le nuove pipeline create (YAML o classica), i tag vengono comunque sincronizzati per impostazione predefinita. Questa opzione non modifica il comportamento delle pipeline esistenti. I tag verranno comunque sincronizzati in tali pipeline, a meno che non si modifichi esplicitamente l'opzione come descritto in precedenza.

Artifacts

Aggiornamento delle autorizzazioni predefinite per il feed

Gli account del servizio compilazione raccolta progetti avranno ora il ruolo Collaboratore per impostazione predefinita quando viene creato un nuovo feed Azure Artifacts con ambito raccolta di progetti, anziché il ruolo Collaboratore corrente.

In precedenza, è possibile visualizzare pacchetti upstream se si dispone di una copia del feed. Il punto di dolore era che non è stato possibile cercare pacchetti disponibili nell'upstream e che non sono ancora stati salvati nel feed. È ora possibile cercare i pacchetti upstream disponibili con la nuova interfaccia utente del feed.

Azure Artifacts offre ora un'interfaccia utente che consente di cercare pacchetti nelle origini upstream e salvare le versioni dei pacchetti nel feed. Questo è allineato all'obiettivo di Microsoft per migliorare i prodotti e i servizi.

Creazione di report

Mostra elemento padre nel widget Risultati query

Il widget Risultati query supporta ora il nome dell'elemento padre e un collegamento diretto a tale elemento padre.

Creare token di accesso personali da distribuire nel Marketplace

Copia dashboard

Con questa versione è inclusa la copia del dashboard.

Immagine con copia dashboard

Data dell'ultimo accesso ai dashboard e modificata da

Una delle sfide per consentire ai team di creare diversi dashboard è la gestione e la pulizia dei dati obsoleti e inutilizzati. Sapere quando un dashboard è stato visitato o modificato per l'ultima volta è una parte importante per comprendere quali possono essere rimossi. In questa versione sono state incluse due nuove colonne nella pagina della directory Dashboard. Data dell'ultimo accesso tiene traccia del momento in cui il dashboard è stato visitato più di recente. Modificato da tiene traccia dell'ultima modifica del dashboard e da chi.

Le informazioni Modificate da verranno visualizzate anche nella pagina del dashboard stessa.

Anteprima del dashboard

Questi nuovi campi consentono agli amministratori del progetto di comprendere il livello di attività per i dashboard per prendere una decisione educata se devono essere rimossi o meno.

Le visualizzazioni di analisi sono ora disponibili

La funzionalità Visualizzazioni analisi è stata in uno stato di anteprima per un lungo periodo di tempo nella versione ospitata del prodotto. Con questa versione siamo lieti di annunciare che questa funzionalità è ora disponibile per tutte le raccolte di progetti.

Nel riquadro di spostamento, le visualizzazioni di Analisi sono state spostate dalla scheda Panoramica alla scheda Boards .

Visualizzazione di analisi nella struttura di spostamento delle schede.

Una visualizzazione Analisi offre un modo semplificato per specificare i criteri di filtro per un report di Power BI in base ai dati di Analisi. Se non si ha familiarità con le visualizzazioni di Analisi, di seguito è riportato un po' di documentazione per ottenere informazioni dettagliate:

Il widget Richiesta pull per più repository è ora disponibile

Siamo lieti di annunciare che il widget Richiesta pull per più repository è disponibile in Azure DevOps Server 2022.1. Con questo nuovo widget, è possibile visualizzare facilmente le richieste pull da un massimo di 10 repository diversi in un unico elenco semplificato, rendendo più semplice che mai rimanere in cima alle richieste pull.

Più widget del repository a disponibilità generale

Ticket di suggerimento della community

Introduzione risolta come completata nei grafici burndown e burnup

È importante comprendere l'importanza di riflettere in modo accurato lo stato del team, inclusi gli elementi risolti completati nei grafici. Con un'opzione di attivazione/disattivazione semplice, è ora possibile scegliere di visualizzare gli elementi risolti come completati, fornendo un vero riflesso dello stato di burndown del team. Questo miglioramento consente un monitoraggio e una pianificazione più accurati, consentendo ai team di prendere decisioni informate in base allo stato effettivo. Esperienza migliorata di trasparenza e informazioni dettagliate migliori con i grafici di burn-down e burnup aggiornati in Creazione di report.

Gif per demo risolta come completata nei grafici burn-down e burn-up.

Wiki

Supporto per altri tipi di diagramma nelle pagine wiki

È stata aggiornata la versione dei grafici mermaid usati nelle pagine wiki alla versione 8.13.9. Con questo aggiornamento è ora possibile includere i diagrammi e le visualizzazioni seguenti nelle pagine wiki di Azure DevOps:

  • Diagramma di flusso
  • Diagrammi sequenza
  • Diagrammi di Gantt
  • Grafici a torta
  • Diagrammi dei requisiti
  • Diagrammi di stato
  • Percorso utente

I diagrammi in modalità sperimentale, ad esempio Relazione entità e Git Graph, non sono inclusi. Per altre informazioni sulle nuove funzionalità, vedere le note sulla versione di mermaid.

Commenti

I commenti degli utenti sono molto apprezzati. È possibile segnalare un problema o fornire un'idea e monitorarla tramite Developer Community e ottenere consigli su Stack Overflow.

In alto