Note sulla versione di Azure DevOps Server 2022 Update 1

---

| Developer Community Requisiti | disistema e condizioni di | licenza di compatibilità | DevOps Blog | SHA-256 Hashes |

---

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 .

Per scaricare Azure DevOps Server prodotti, visitare la pagina Azure DevOps Server Download.

L'aggiornamento diretto a 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 a Azure DevOps Server 2022. Per altre informazioni, vedere la pagina Installa .

---

Azure DevOps Server 2022 Update 1 Patch 3 Data di rilascio: 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 per cui 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.

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

File	Hash SHA-256
devops2022.1patch2.exe	59B3191E86DB787F91FD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

È 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 utilizzato dalla cartella della cache proxy è stato calcolato in modo non corretto e la cartella non è stata pulita correttamente.
• CVE-2024-20667: vulnerabilità di esecuzione del codice remoto Azure DevOps Server.

Azure DevOps Server 2022 Update 1 Patch 1 Data di rilascio: 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.

Azure DevOps Server 2022 Update 1 Data di rilascio: 28 novembre 2023

Nota

Esistono due problemi noti con questa versione:

1. La versione dell'agente non viene aggiornata dopo l'aggiornamento a 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 nel Developer Community durante l'avanzamento. Nel frattempo, è possibile trovare una soluzione alternativa per questo problema in questo ticket di Developer Community.
2. Compatibilità maven 3.9.x. Maven 3.9.x ha introdotto modifiche di rilievo con Azure Artifacts aggiornando il trasporto predefinito del resolver Maven a HTTP nativo da Wagon. Ciò causa 401 problemi di autenticazione 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 del sistema di risoluzione dei carri. Per altri dettagli, vedere la documentazione qui .

Azure DevOps Server 2022.1 è un rollup di correzioni di bug. Include tutte le funzionalità del 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 predefinito del resolver Maven a HTTP nativo da Wagon. Ciò causa 401 problemi di autenticazione 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 del sistema di risoluzione dei carri. Per altri dettagli, vedere la documentazione qui .

data di rilascio 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à del 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 predefinito del resolver Maven a HTTP nativo da Wagon. Ciò causa 401 problemi di autenticazione 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 del sistema di risoluzione dei carri. Per altri dettagli, vedere la documentazione qui .

La versione seguente è stata risolta:

• È stato risolto un problema nei feed locali per cui le voci upstream non risolvevano le modifiche al nome visualizzato.
• Si è verificato un errore imprevisto durante il passaggio delle 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 o i file del progetto team includono CJK.
• È stato risolto un problema durante l'installazione della ricerca per 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 Elastic Search e quindi rimuove la dipendenza da qualsiasi Java Runtime Environment (JRE) preinstallato nel server di destinazione.

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

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

• Tutte le API REST pubbliche supportano ambiti PAT granulari
• Ultima colonna a cui si accede nella pagina Piani di recapito
• Visualizzare tutte le dipendenze dai piani di recapito
• macro @CurrentIteration nei piani di recapito
• Il progetto corrente è impostato come ambito predefinito per il token di accesso di compilazione nelle pipeline classiche
• Mostra elemento padre nel widget Risultati query
• Copia dashboard
• Supporto per altri tipi di diagramma nelle pagine wiki
• Le connessioni al servizio Registro Container possono ora usare identità gestite di Azure

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

• Generale
• Boards
• Repos
• Pipeline
• Elementi
• Creazione di report
• Wiki

---

Generale

Tutte le API REST pubbliche supportano ambiti PAT granulari

In precedenza, una serie di API REST di Azure DevOps documentate pubblicamente non erano associate a ambiti (ad esempio, lettura di 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 pat con ambito completo per eseguire l'autenticazione in 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 disponibile una tabella di ambiti qui.

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, dopo l'installazione, 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. Sono state ora aggiunte le autorizzazioni di estensione alle impostazioni dell'estensione che consentono di esaminare e prendere una decisione informata su se mantenerle o meno.

Boards

Ultima colonna a cui si accede nella pagina Piani di recapito

La pagina della directory Piani di recapito contiene 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. In questo modo viene fornita 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.

Visualizzare tutte le dipendenze dai piani di recapito

I piani di recapito hanno sempre offerto 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 tra tutti gli elementi di lavoro sullo schermo. È sufficiente fare clic sul pulsante Attiva/Disattiva dipendenze in alto a destra del piano di recapito. Fare di nuovo clic per disattivare le righe.

Nuovi limiti di revisione dell'elemento 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. Ciò crea problemi con le prestazioni e l'usabilità nel modulo dell'elemento di lavoro e nelle API REST per la creazione di report. Per attenuare il problema, è stato implementato un limite di revisione degli elementi di lavoro di 10.000 al servizio Azure DevOps. Il limite influisce solo sugli aggiornamenti usando 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 dei 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.

Correzione di un bug nei collegamenti all'elemento di lavoro per la creazione di report- Ottenere l'API

È stato risolto un bug nell'API Get dei collegamenti degli 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 rilevate diverse istanze di 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 per le 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 velocità quando si tenta di eseguire qualsiasi tipo di pulizia di massa. In risposta, è stato aggiunto un nuovo endpoint 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 @CurrentIteration macro per gli stili in Piani di recapito. Questa macro consentirà di ottenere l'iterazione corrente dal contesto del team di ogni riga del piano.

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 del modo in cui vengono usate.

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

Miglioramenti apportati all'aggiornamento in batch

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

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

API di eliminazione batch

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

Impedisci la modifica dei campi elenco a discesa condivisibili

I campi personalizzati vengono condivisi tra processi. Ciò 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 dell'elenco a discesa. Possono aggiungere o rimuovere il campo solo dal processo.

Nuova autorizzazione salva commenti

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

"Voglio impedire ad alcuni utenti di modificare i campi degli elementi 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 dell'area desiderato e fare clic su Sicurezza.

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 a un utente di salvare i commenti, selezionare tale gruppo/utenti e modificare l'autorizzazione in Consenti.

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

Speriamo che ami questa funzionalità tanto quanto noi. Come sempre, se si hanno commenti o suggerimenti, inviare commenti e suggerimenti.

Report sulle bacheche interattive

I report interattivi, situati nell'hub Boards, sono stati accessibili da diversi anni nella nostra versione ospitata del prodotto. Sostituiscono i precedenti grafici Diagramma di flusso cumulativo, 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 Sprints.

Repos

Rimozione dell'autorizzazione "Modifica criteri" per creatore di rami

In precedenza, quando è stato creato un nuovo ramo, viene 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.

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.

Pipelines

Il progetto corrente è impostato come ambito predefinito per il token di accesso di 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 al 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 viene impostato l'ambito di autorizzazione del processo 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 ai repository, agli artefatti e ad 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, durante la creazione di una nuova pipeline, 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 San Diego, Tokyo & versioni dello 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. Ora abbiamo aggiornato l'app per lavorare con le versioni di San Diego, Tokyo & Utah di ServiceNow. Per garantire il funzionamento di questa integrazione, 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 GitHub Enterprise Integration

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 il traffico seguente venga instradato 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 Azure Pipelines self-hosted, eliminando la necessità di gestire le credenziali.

Nota

L'identità gestita usata per accedere a Registro Azure Container richiederà l'assegnazione di Controllo di accesso (RBAC) appropriata, ad esempio 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 Di Azure quando si accede al servizio Azure Kubernetes per altre informazioni, per altre informazioni, vedere il post di blog Relativo alla connessione al servizio Azure Kubernetes per i clienti del servizio Azure 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, installarla 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 di 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 l'uso della 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 e dei controlli della pipeline

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 i controlli per tale risorsa.

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

• Aggiornare un'approvazione supporta l'ambitoPipeline Resources Use
• Manage Checks supporta l'ambito Pipeline Resources Use and Manage
• Aggiornare le autorizzazioni della pipeline per le risorse supporta l'ambito Pipeline Resources Use and Manage
• Authorize Definition Resources supporta l'ambito Pipeline Resources Use and Manage
• Autorizzare le risorse del progetto supporta l'ambito Pipeline Resources Use and Manage

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, per consentire a qualsiasi pipeline di usare una connessione al servizio è necessario un ruolo amministratore di servizio generale Connections. Questa restrizione si applica quando si crea una risorsa protetta o quando si modifica la relativa 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.

inoltre, quando si tenta di aprire l'accesso a una risorsa esistente e non si dispone di diritti sufficienti, si otterrà un oggetto Non si è autorizzati ad aprire l'accesso per questo messaggio di risorsa.

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. Questi 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 questo sforzo, 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 personalizzati, la gestione delle pipeline a cui è possibile accedere è stata con granularità grossolana. È possibile consentire l'uso di tutte le pipeline oppure richiedere l'autorizzazione per ogni pipeline. 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 l'Connections del servizio.

Impedire la concessione dell'accesso a tutte le pipeline 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 accidentale di troppi 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.

Possibilità di disabilitare la maschera per i segreti brevi

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

Tutte le occorrenze del valore segreto vengono mascherate. Mascherando i segreti brevi, ad esempio '', '1', 'Dev2' rende facile indovinare i loro valori, ad esempio in una data: 'Jan 3, 202***'
È 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 preso da Key Vault), è possibile impostare il AZP_IGNORE_SECRETS_SHORTER_THAN knob su un valore fino a 4.

Attività di download del runner del nodo

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

L'attività seguente è un metodo per installare il just-in-time del nodo 6, in modo che un'attività precedente possa comunque eseguire:

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

Convalida del nodo TFX aggiornata

Gli autori di attività usano lo strumento di creazione pacchetti di estensioni (TFX) per pubblicare le estensioni. TFX è stato aggiornato per eseguire le convalida nelle versioni del runner del nodo, vedere Il post di blog sulle linee guida sui nodi.

Le estensioni che contengono attività usando il runner Node 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 pre-installazione manuale degli agenti della pipeline del nodo 6

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 Microsoft API Graph

Sono state aggiornate le attività di rilascio per l'uso del API Graph Microsoft. Ciò rimuove l'utilizzo del API Graph AAD dalle nostre attività.

miglioramento delle prestazioni delle attività 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 indirizzare un ambiente di Azure, è possibile usare l'attività AzurePowerShell@5 . Alcuni comandi di PowerShell che possono stampare gli aggiornamenti dello stato, ad esempio Invoke-WebRequest, ora vengono eseguiti più velocemente. Il miglioramento è più significativo se si hanno 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 l'uso di .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, si rilascia il supporto per i sistemi operativi seguenti: CentOS 6, Fedora 29-33, Linux Mint 17-18, Red Hat Enterprise Linux 6. Vedere la documentazione del software Agent 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 aggiorneranno più o non riusciranno dopo l'implementazione dell'agente basato su .NET 6.

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

La macchina virtuale di Azure può essere inclusa nei gruppi di distribuzione usando un'estensione della macchina virtuale. L'estensione della macchina virtuale è stata aggiornata per specificare facoltativamente la versione dell'agente desiderata da installare:

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

Nuove opzioni 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 rilascio classiche, gruppi di attività e gruppi di distribuzione. Le pipeline classiche esistenti continueranno a essere eseguite e saranno in grado di 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 rilascio classiche, gruppi di attività e gruppi di distribuzione. Le pipeline classiche esistenti continueranno a essere eseguite e saranno in grado di modificarle, ma non sarà possibile crearne di nuove.

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

Lo stato di attivazione è disattivato per impostazione predefinita e sarà necessario diritti di amministratore per modificare lo stato. Se l'interruttore è attivo 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 di hook del servizio "Esegui stato di fase modificato"

Gli hook di servizio consentono di eseguire attività su altri servizi quando si verificano eventi nel progetto in Azure DevOps, lo stato della fase di esecuzione è uno di questi eventi. L'evento Run stage state modificato 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.

Questo messaggio può essere confuso, ad esempio quando il codice della pipeline YAML vive in un repository diverso da quello che contiene il codice che sta creando. Abbiamo sentito il feedback dell'Developer Community chiedendoci un modo per abilitare/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 appendCommitMessageToRunName, che consente di eseguire esattamente questa operazione. Per impostazione predefinita, la proprietà è impostata su true. Quando lo si imposta su false, l'esecuzione della pipeline visualizzerà solo .BuildNumber

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

È possibile usare l'attività Distribuzione modelli di Azure Resource Manager per creare l'infrastruttura di Azure. In risposta al feedback, è stato aumentato il limite di integrazione di Azure Pipelines di 2 MB a 4 MB. In questo modo verranno allineate le dimensioni massime dei modelli arm di 4 MB che risolvono 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 completata. E se è terminato, qual è lo stato complessivo: esito positivo, non riuscito o annullato. È stato risolto questo problema aggiungendo un'icona di panoramica dello stato di esecuzione.

Pannello laterale fasi della pipeline

Le pipeline YAML possono avere decine di fasi e non tutte si adattano sullo schermo. Mentre l'icona panoramica dell'esecuzione della pipeline indica lo stato complessivo dell'esecuzione, è comunque 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 log.

Cercare 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 in esecuzione o quelle che richiedono un intervento manuale. È anche possibile cercare le fasi in base al nome.

Azioni rapide di fase

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 eseguire facilmente processi non riusciti o eseguire nuovamente l'intera fase. Il pannello è disponibile quando non tutte le fasi rientrano nell'interfaccia utente, come si può vedere nello screenshot seguente.

Quando si fa clic sulla colonna "+" per accedere alla colonna fasi, viene visualizzato il pannello fasi e quindi è possibile eseguire azioni di fase.

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.

Per evitare approvazioni approvate erroneamente, Azure DevOps mostra le istruzioni per i responsabili approvazione nel pannello Approvazioni e controlli sul lato di una pipeline nella pagina dei dettagli dell'esecuzione 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 impedire che blocchino erroneamente una distribuzione. Dopo aver corretto il controllo, è stato 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.

Dopo aver corretto il controllo errato, è sufficiente abilitarlo.

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

L'API REST Pipelines Runs ora restituisce 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 scrivere controlli di conformità che valutano i repository, i contenitori e altre esecuzioni di pipeline usate da una pipeline.

Ecco 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 dei modelli 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 sono riusciti a 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.

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 ha esito negativo 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 nelle pipeline di compilazione classiche.

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 consentono di 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 in cui eseguire la distribuzione è definito dalla stringa integration1, integration2.

Durante l'ascolto dei commenti e suggerimenti degli Developer Community, è stata rilevata la conversazione di una funzione stringa split nelle espressioni di modello YAML.

È ora possibile split eseguire un'iterazione each di una stringa sulle 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 durante la definizione della ref proprietà di una repository risorsa in una pipeline YAML. Questa è stata una funzionalità molto richiesta dal nostro Developer Community.

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

Si supponga, ad esempio, di avere una pipeline che compila il proprio repository e, per questo, deve eseguire il check-out di 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, il ramo della libreria deve essere estratto dev .

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

È ora 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 emigliorare 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 indicato di seguito:

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'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 e sistema variabili predefinite, ma non è possibile usare variabili YAML o Pipelines definite dall'interfaccia utente.

Espressioni modello nella definizione di risorsa contenitore

È stato aggiunto il supporto per le espressioni modello durante la definizione delle endpointproprietà , volumes, portse options di una container risorsa in una pipeline YAML. Questa è stata una funzionalità molto richiesta dal nostro Developer Community.

È ora possibile scrivere pipeline YAML come illustrato di seguito.

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 modello. Per le variabili, è possibile usare solo quelli definiti nel file YAML, ma non quelli definiti nell'interfaccia utente di Pipelines. Se si ridefinirà 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 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, dichiarando 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à il messaggio simile al seguente: i dati di pianificazione della compilazione sono danneggiati se una pipeline non riesce a caricare.

Non sincronizzare i tag durante il recupero di un repository Git

L'attività di pagamento 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 i tag. Ciò aumenta il tempo 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 pagamento sincronizza i tag anche quando si abilita l'opzione di recupero superficiale, quindi eventualmente sconfiggendone lo scopo. Per ridurre la quantità di dati recuperati o estratti da un repository Git, è ora stata aggiunta una nuova opzione all'attività per controllare il comportamento dei tag di sincronizzazione. Questa opzione è disponibile sia nelle pipeline CLASSIC che YAML.

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 l'oggetto fetchTags: false al passaggio di estrazione. Quando l'opzione fetchTags non è specificata, è uguale a se fetchTags: true 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ù pratico 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 Processo e quindi il passaggio Checkout.

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

Classico

Per rifiutare esplicitamente la sincronizzazione dei tag, deselezionare la casella di controllo Sincronizza tag nel passaggio get sources.

Per tutte le nuove pipeline create (YAML o Classic), i tag vengono ancora 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 modifica esplicitamente l'opzione come descritto in precedenza.

Artifacts

Autorizzazioni di feed predefinite aggiornate

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

Nuova interfaccia utente per la ricerca di pacchetti upstream

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

Gli artefatti di Azure forniscono ora un'interfaccia utente che consente di cercare pacchetti nelle origini upstream e salvare le versioni dei pacchetti nel feed. Ciò si allinea all'obiettivo di Microsoft di migliorare i prodotti e i servizi.

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.

Copia dashboard

Con questa versione è incluso Copy Dashboard.

Dashboard ultima data di accesso e modificata da

Una delle sfide che consentono ai team di creare diversi dashboard è la gestione e la pulizia dell'oggetto obsoleto e inutilizzato. Sapere quando un dashboard è stato visitato o modificato è una parte importante per comprendere quali possono essere rimossi. In questa versione sono state incluse due nuove colonne nella pagina directory Dashboards. L'ultima data di accesso verrà tracciata quando il dashboard è stato visitato più di recente. Modificato Da traccia quando il dashboard è stato modificato e da chi.

Le informazioni modificate verranno visualizzate anche nella pagina del dashboard stessa.

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 periodo di tempo esteso nella versione ospitata del prodotto. Con questa versione siamo lieti di annunciare che questa funzionalità è ora disponibile per tutte le raccolte di progetti.

Nella finestra di spostamento, le visualizzazioni analisi sono state spostate dalla scheda Panoramica alla scheda 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, ecco una documentazione per acquisire familiarità:

• Informazioni sulle visualizzazioni di Analisi
• Creare una visualizzazione analisi in Azure DevOps
• Gestire le visualizzazioni di Analisi
• Creare un report di Power BI con una visualizzazione analisi predefinita
• Connettersi ad Analytics con Power BI Data Connector

Il widget richiesta pull per più repos è 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 fino a 10 repository diversi in un unico elenco semplificato, semplificando il tempo di rimanere in cima alle richieste pull.

Ticket di suggerimento per la community

Introduzione risolta come completata nei grafici di burndown e burnup

Si comprende l'importanza di riflettere in modo accurato lo stato del team, inclusi gli elementi risolti come completati nei grafici. Con un'opzione di disattivazione semplice, è ora possibile scegliere di visualizzare gli elementi risolti come completato, fornendo una vera riflessione dello stato di burndown del team. Questo miglioramento consente un rilevamento e una pianificazione più accurati, consentendo ai team di prendere decisioni informate in base all'effettivo avanzamento. Esperienza di trasparenza migliorata e informazioni dettagliate migliori con i grafici di burndown e burnup aggiornati in Creazione di report.

Wiki

Supporto per i tipi di diagramma aggiuntivi 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 di entità e Git Graph, non sono inclusi. Per altre informazioni sulle nuove funzionalità, vedere le note sulla versione del mermaid.

---

Commenti e suggerimenti

Le opinioni dei nostri clienti sono molto importanti per noi. È possibile segnalare un problema o fornire un'idea e tenere traccia di esso attraverso Developer Community e ottenere consigli su Stack Overflow.

---

Inizio pagina