Note sulla versione di Azure DevOps Server 2022

---

| 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 è 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 0.1 Patch 5 Data di rilascio: 14 novembre 2023

Nota

Azure DevOps Server patch sono cumulative, se non è stata installata la patch 3, questa patch include gli aggiornamenti all'agente di Azure Pipelines. La nuova versione dell'agente dopo l'installazione della patch 5 sarà 3.225.0.

File	Hash SHA-256
devops2022.0.1patch5.exe	DC4C7C3F9AF1CC6C16F7562DB4B2295E1318C1A180ADA079D636CCA47A6C1022

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

• Estensione dell'elenco di caratteri consentiti per Abilitare la convalida dei parametri degli argomenti delle attività della shell.
• Consente di risolvere un problema che causava la persistente modifica delle connessioni al servizio dopo aver fatto clic sul pulsante Annulla.

Azure DevOps Server 2022 Update 0.1 Patch 4 Data di rilascio: 10 ottobre 2023

Nota

Azure DevOps Server patch sono cumulative, se non è stata installata la patch 3, questa patch include gli aggiornamenti all'agente di Azure Pipelines. La nuova versione dell'agente dopo l'installazione della patch 5 sarà 3.225.0.

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

• Correzione di un bug che causava il blocco delle pipeline aggiornando il modello di esecuzione della pipeline.
• Correzione di un bug per cui l'identità "Proprietario analisi" mostrava l'identità inattiva nei computer di aggiornamento delle patch.
• Il processo di pulizia della compilazione contiene molte attività, ognuna delle quali elimina un artefatto per una compilazione. Se una di queste attività non è riuscita, nessuna delle attività successive è stata eseguita. Questo comportamento è stato modificato per ignorare gli errori delle attività e pulire tutti gli artefatti che è possibile eseguire.

Azure DevOps Server 2022 Update 0.1 Patch 3 Data di rilascio: 12 settembre 2023

Nota

Questa patch include gli aggiornamenti dell'agente di Azure Pipelines. La nuova versione dell'agente dopo l'installazione della patch 3 sarà 3.225.0.

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

• CVE-2023-33136: Azure DevOps Server vulnerabilità di esecuzione del codice remoto.
• CVE-2023-38155: vulnerabilità di elevazione dei privilegi di Azure DevOps Server e Team Foundation Server.

Azure DevOps Server 2022 Update 0.1 Patch 2 Data di rilascio: 8 agosto 2023

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

• CVE-2023-36869: vulnerabilità di spoofing Azure DevOps Server.
• Correzione di un bug nelle chiamate SOAP in cui è possibile alzare ArithmeticException per una risposta XML di metadati di grandi dimensioni.
• Implementazione delle modifiche apportate all'editor delle connessioni al servizio in modo che lo stato dell'endpoint venga scaricato nel componente ignora.
• È stato risolto un problema con i collegamenti relativi che non funzionano nei file markdown.
• È stato risolto un problema di prestazioni relativo al livello applicazione che richiede più tempo del normale all'avvio quando è definito un numero elevato di tag.
• Sono stati risolti TF400367 errori nella pagina Pool di agenti.
• Correzione di un bug per cui l'identità del proprietario dell'analisi è stata mostrata come identità inattiva.
• Correzione del bug del ciclo infinito in CronScheduleJobExtension.

Azure DevOps Server 2022 Update 0.1 Patch 1 Data di rilascio: 13 giugno 2023

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

• CVE-2023-21565: vulnerabilità di spoofing Azure DevOps Server.
• CVE-2023-21569: vulnerabilità di spoofing Azure DevOps Server.
• Correzione di un bug con l'editor delle connessioni al servizio. A questo punto, lo stato dell'endpoint bozza viene scaricato in caso di chiusura del componente.
• Correzione di un bug per cui la raccolta di scollegamento o collegamento non riesce a segnalare l'errore seguente: 'TF246018: l'operazione del database ha superato il limite di timeout ed è stata annullata.

Azure DevOps Server 2022 Update 0.1 Data di rilascio: 9 maggio 2023

Azure DevOps Server 2022.0.1 è un rollup di correzioni di bug. Include tutte le correzioni nella Azure DevOps Server 2022.0.1 RC rilasciata in precedenza. È possibile installare direttamente Azure DevOps Server 2022.0.1 o eseguire l'aggiornamento da Azure DevOps Server 2022 o Team Foundation Server 2015 o versione successiva.

Azure DevOps Server 2022 Update 0.1 RC Data di rilascio: 11 aprile 2023

Azure DevOps Server 2022.0.1 RC è un rollup di correzioni di bug. Include tutte le correzioni nelle patch Azure DevOps Server 2022 rilasciate in precedenza. È possibile installare direttamente Azure DevOps Server 2022.0.1 o eseguire l'aggiornamento da Azure DevOps Server 2022 o Team Foundation Server 2015 o versione successiva.

Questa versione include correzioni per i bug seguenti:

• Aggiornamento di Git Virtual File System (GVFS) da a v2.39.1.1-micorosoft.2 per risolvere una vulnerabilità di sicurezza.
• I dati di test non sono stati eliminati, causando l'aumento del database. Con questa correzione, è stata aggiornata la conservazione della compilazione per impedire la creazione di nuovi dati di test orfani.
• Aggiornamenti a AnalyticCleanupJob, lo stato del processo è stato Arrestato e ora è stato restituito Succeeded.
• Correzione del comando "tfx extension publish" con errore "The given key was not present in the dictionary".
• È stata implementata una soluzione alternativa per risolvere e risolvere gli errori durante l'accesso all'estensione Calendario del team.
• CVE-2023-21564: vulnerabilità di scripting tra siti Azure DevOps Server
• CVE-2023-21553: vulnerabilità di esecuzione del codice remoto Azure DevOps Server
• Aggiornamento delle attività MSBuild e VSBuild per supportare Visual Studio 2022.
• Metodologia di aggiornamento del caricamento della riautenticazione per impedire il vettore di attacco XSS.
• Azure DevOps Server 2022 Proxy segnala l'errore seguente: VS800069: questo servizio è disponibile solo in Azure DevOps locale.
• Correzione del problema di accessibilità degli scaffali tramite l'interfaccia utente Web.
• È stato risolto un problema che richiedeva il riavvio del servizio tfsjobagent e Azure DevOps Server pool di applicazioni dopo l'aggiornamento dell'impostazione correlata a SMTP nella console di gestione di Azure DevOps Server.
• Le notifiche non vengono inviate per pat sette giorni prima della data di scadenza.

Azure DevOps Server 2022 Patch 4 Data di rilascio: 13 giugno 2023

È stata rilasciata una patch per Azure DevOps Server 2022 che include correzioni per quanto segue.

• CVE-2023-21565: vulnerabilità di spoofing Azure DevOps Server.
• CVE-2023-21569: vulnerabilità di spoofing Azure DevOps Server.
• Correzione di un bug con l'editor delle connessioni al servizio. A questo punto, lo stato dell'endpoint bozza viene scaricato in caso di chiusura del componente.
• Correzione di un bug per cui la raccolta di scollegamento o collegamento non riesce a segnalare l'errore seguente: 'TF246018: l'operazione del database ha superato il limite di timeout ed è stata annullata.

Azure DevOps Server 2022 Patch 3 Data di rilascio: 21 marzo 2023

È stata rilasciata una patch (19.205.33506.1) per Azure DevOps Server 2022 che include correzioni per quanto segue.

• È stato risolto un problema che richiedeva il riavvio del servizio tfsjobagent e Azure DevOps Server pool di applicazioni dopo l'aggiornamento dell'impostazione correlata a SMTP nella console di gestione di Azure DevOps Server.
• Copiare lo stato dell'endpoint nel pannello di modifica dell'endpoint di servizio anziché passarlo per riferimento.
• In precedenza, durante la modifica delle connessioni al servizio, le modifiche sono state rese persistenti nell'interfaccia utente dopo aver selezionato il pulsante Annulla. Con questa patch, è stato risolto in Notification SDK per quando un team ha impostato il recapito delle notifiche su Non recapitare. In questo scenario, se la sottoscrizione di notifica è configurata con l'opzione di recapito delle preferenze team , i membri del team non riceveranno le notifiche. Non è necessario espandere ulteriormente le identità nel team per controllare le preferenze dei membri.

Azure DevOps Server 2022 Patch 2 Data di rilascio: 14 febbraio 2023

È stata rilasciata una patch per Azure DevOps Server 2022 che include correzioni per quanto segue.

• CVE-2023-21564: vulnerabilità di scripting tra siti Azure DevOps Server
• Aggiornamento delle attività MSBuild e VSBuild per supportare Visual Studio 2022.
• Metodologia di aggiornamento del caricamento della riautenticazione per evitare possibili vettori di attacco XSS.
• Azure DevOps Server 2022 Proxy segnala l'errore seguente: VS800069: questo servizio è disponibile solo in Azure DevOps locale.

Azure DevOps Server 2022 Patch 1 Data di rilascio: 24 gennaio 2023

È stata rilasciata una patch per Azure DevOps Server 2022 che include correzioni per quanto segue.

• I dati di test non sono stati eliminati, causando l'aumento del database. Con questa correzione, la conservazione della compilazione è stata aggiornata per impedire la creazione di nuovi dati di test orfani.
• Aggiornamenti a AnalyticsCleanupJob, lo stato del processo è stato arrestato e ora è stato eseguito il report Riuscito.
• Correzione del comando "tfx extension publish" con errore "La chiave specificata non è stata presente nel dizionario".
• Implementata una soluzione alternativa per risolvere e risolvere gli errori durante l'accesso all'estensione Calendario team.

data di rilascio Azure DevOps Server 2022: 6 dicembre 2022

Azure DevOps Server 2022 è un roll up di correzioni di bug. Include tutte le funzionalità del Azure DevOps Server 2022 RC2 e RC1 precedentemente rilasciate.

Azure DevOps Server 2022 RC2 Data di rilascio: 25 ottobre 2022

Azure DevOps Server 2022 RC2 è un roll up di correzioni di bug. Include tutte le funzionalità del Azure DevOps Server 2022 RC1 rilasciate in precedenza.

Nota

Nuovi algoritmi RSA SSH abilitati

Il supporto della chiave pubblica RSA è stato migliorato per supportare i tipi di chiavi pubbliche SHA2 oltre a SHA1 SSH-RSA precedentemente supportati.

Ora i tipi di chiave pubblica supportati includono:

• SSH-RSA
• RSA-SHA2-256
• RSA-SHA2-512

Azione richiesta

Se è stato implementato il funzionamento per abilitare SSH-RSA specificandolo in modo esplicito nel .ssh/config1 file, è necessario rimuoverlo PubkeyAcceptedTypeso modificarlo per usare RSA-SHA2-256 o RSA-SHA2-512 o entrambi. È possibile trovare informazioni dettagliate su cosa fare se viene ancora richiesto per la password e GIT_SSH_COMMAND="ssh -v" git fetch non viene visualizzato alcun algoritmo di firma reciproca nella documentazione qui.

Il supporto della chiave ellittica non è ancora stato aggiunto e rimane una funzionalità altamente richiesta nel backlog.

data di rilascio Azure DevOps Server 2022 RC1: 9 agosto 2022

Riepilogo delle novità in Azure DevOps Server 2022

Importante

Warehouse e Analysis Service è stato deprecato nella versione precedente di Azure DevOps Server (2020). In Azure DevOps Server 2022 il servizio Warehouse e Analysis Service è stato rimosso dal prodotto. Analisi offre ora l'esperienza di creazione di report in-product.

Azure DevOps Server 2022 introduce molte nuove funzionalità. Tra le caratteristiche principali:

• Piani di recapito
• Visualizzare la persona corretta nei collegamenti di commit
• Nuovi controlli per le variabili di ambiente nelle pipeline
• Generare un token senza restrizioni per le compilazioni fork
• Nuove pagine TFVC
• Raggruppa per tag disponibili nei widget del grafico

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

• Boards
• Repos
• Pipeline
• Creazione di report

---

Boards

Piani di recapito

Siamo lieti di annunciare che i piani di recapito sono ora inclusi in Azure DevOps Server. I piani di recapito offrono 3 scenari chiave:

• Visualizzazione temporale del piano
• Avanzamento del lavoro
• Rilevamento delle dipendenze

Di seguito sono riportate le funzionalità principali. Il filtro, i marcatori e i criteri di campo fanno parte anche dei piani di recapito.

Esistono due viste principali: condensata ed espansa

I piani di recapito 2.0 consentono di visualizzare tutti gli elementi di lavoro nel piano in una sequenza temporale, usando le date di inizio e di destinazione o le date di iterazione. L'ordine della precedenza viene avviato & date di destinazione, quindi seguite dall'iterazione. In questo modo è possibile aggiungere elementi di lavoro a livello di portfolio comeEpic che spesso non sono definiti in un'iterazione.

Sono disponibili due viste principali della visualizzazione condensata e della visualizzazione espansa. È anche possibile ingrandire e uscire dal piano facendo clic sulla lente di ingrandimento sul lato ight-hand del piano.

Sono disponibili due viste principali della visualizzazione condensata e della visualizzazione espansa. È anche possibile ingrandire e uscire dal piano facendo clic sulla lente di ingrandimento sul lato destro del piano.

• Visualizzazione condensata

  La visualizzazione condensata mostra tutte le schede dell'elemento di lavoro compresse , ovvero che non tutte le informazioni sulla scheda vengono visualizzate. Questa vista è utile per una visione complessiva del lavoro nel piano. Per comprimere i campi della scheda, fare clic sull'icona della scheda accanto alle icone di ingrandimento sul lato destro del piano.

  Ecco un esempio di un interruttore di piano tra le viste condensate e espanse.

  

• Visualizzazione espansa

  La visualizzazione espansa mostra lo stato di avanzamento di un elemento di lavoro conteggiando il numero di elementi figlio e collegati e visualizzando la percentuale completa. Attualmente lo stato di avanzamento è determinato dal conteggio degli elementi di lavoro.

  Ecco un esempio di piano usando una visualizzazione espansa. Si notino le barre di stato e la percentuale completa.

  

Rilevamento delle dipendenze

Il rilevamento delle dipendenze si basa sui collegamenti predecessori e successore definiti negli elementi di lavoro. Se tali collegamenti non sono definiti, non verranno visualizzate righe di dipendenza. Quando si verifica un problema di dipendenza con un elemento di lavoro, l'icona del collegamento alle dipendenze è colorata in rosso.

• Visualizzazione delle dipendenze

  Le dipendenze specifiche vengono visualizzate tramite il pannello delle dipendenze che mostra tutte le dipendenze per tale elemento di lavoro, inclusa la direzione. Un punto esclamativo rosso indica un problema di dipendenza. Per visualizzare il pannello, fare semplicemente clic sull'icona del collegamento di dipendenza nell'angolo superiore destro della scheda. Ecco alcuni esempi di dipendenze.

  

  

• Righe di dipendenza

  Le dipendenze tra gli elementi di lavoro vengono visualizzate con linee freccia direzionali tra i rispettivi elementi di lavoro. Più dipendenze verranno visualizzate come più righe. Una linea colorata rossa indica un problema.

  Di seguito sono riportati alcuni esempi.

  

  Ecco un esempio di un elemento di lavoro con più dipendenze e funziona anche usando la visualizzazione condensata.

  

  Quando si verifica un problema, il colore della linea è rosso e quindi è l'icona di dipendenza.

  Ecco un esempio.

  

Stile schede

Le schede possono ora essere in stile usando regole, ad esempio le schede Kanban. Aprire le impostazioni del piano e fare clic su Stili. Nel riquadro Stili fare clic su + Aggiungi regola di stile per aggiungere la regola e quindi fare clic su Salva. Possono essere presenti fino a 10 regole e ogni regola può avere fino a 5 clausole.

• Prima

• After

Per altre informazioni sui piani di recapito, vedere la documentazione qui.

Elementi rimossi nell'hub elementi di lavoro

L'hub elementi di lavoro è il posto per visualizzare un elenco di elementi creati o assegnati all'utente. Offre diverse funzioni pivot e filtro personalizzate per semplificare l'inserimento di elementi di lavoro. Uno dei principali reclami del pivot Assegnato a me è che visualizza elementi di lavoro rimossi. Siamo d'accordo che gli elementi di lavoro rimossi non sono più di valore e non devono trovarsi nel backlog. In questo sprint si nasconderanno tutti gli elementi rimossi dalle visualizzazioni Assegnate a me nell'hub elementi di lavoro.

Visualizzare la persona corretta nei collegamenti di commit

La sezione di sviluppo in un elemento di lavoro mostra l'elenco di commit e richieste pull pertinenti. È possibile visualizzare l'autore della richiesta di commit o pull insieme all'ora associata. Con questo aggiornamento è stato risolto un problema con l'avatar dell'autore visualizzato in modo errato nella visualizzazione.

Rimuovere la possibilità di scaricare un allegato eliminato dalla cronologia degli elementi di lavoro

È stato risolto un piccolo problema per cui gli utenti erano in grado di scaricare allegati dalla cronologia dell'elemento di lavoro, anche dopo che l'allegato è stato rimosso dal modulo. Ora, una volta rimosso l'allegato, non può essere scaricato dalla cronologia, né l'URL di download sarà disponibile dalla risposta dell'API REST.

Aggiunto il valore "Will not Fix" nel campo Motivo bug

Come per tutti gli altri tipi di elemento di lavoro, il tipo di elemento di lavoro Bug ha un flusso di lavoro ben definito. Ogni flusso di lavoro è costituito da tre o più stati e da un motivo. Motivi per specificare il motivo per cui l'elemento è passato da uno stato a un altro. Con questo aggiornamento è stato aggiunto un valore di motivo non corretto per i tipi di elemento di lavoro Bug nel processo Agile. Il valore sarà disponibile come motivo per lo spostamento di bug da Nuovo o Attivo a Risolto. Per altre informazioni su come definire, acquisire, valutare e gestire i bug software nella documentazione di Azure Boards.

Pipelines

Rimozione dei criteri di conservazione per pipeline nelle compilazioni classiche

È ora possibile configurare i criteri di conservazione per le build classiche e le pipeline YAML nelle impostazioni del progetto Azure DevOps. Le regole di conservazione per pipeline per pipeline classiche non sono più supportate. Sebbene si tratta dell'unico modo per configurare la conservazione per le pipeline YAML, è anche possibile configurare la conservazione per le pipeline di compilazione classiche in base alla pipeline. Sono state rimosse tutte le regole di conservazione per pipeline per pipeline di compilazione classiche in una versione futura.

Ciò significa che tutte le pipeline di compilazione classiche usate per avere regole di conservazione per pipeline verranno regolate dalle regole di conservazione a livello di progetto.

Per assicurarsi di non perdere alcuna compilazione durante l'aggiornamento, verrà creato un lease per tutte le build esistenti al momento dell'aggiornamento che non hanno un lease.

È consigliabile controllare le impostazioni di conservazione a livello di progetto dopo l'aggiornamento. Se la pipeline richiede in modo specifico regole personalizzate, è possibile usare un'attività personalizzata nella pipeline. Per informazioni sull'aggiunta di lease di conservazione tramite un'attività, vedere la documentazione imposta i criteri di conservazione per compilazioni, versioni e test.

Nuovi controlli per le variabili di ambiente nelle pipeline

L'agente di Azure Pipelines analizza l'output standard per i comandi di registrazione speciali e li esegue. Il setVariablecomando può essere usato per impostare una variabile o modificare una variabile definita in precedenza. Ciò può potenzialmente essere sfruttato da un attore all'esterno del sistema. Ad esempio, se la pipeline ha un passaggio che stampa l'elenco di file in un server ftp, una persona con accesso al server ftp può aggiungere un nuovo file, il cui nome contiene il setVariable comando e causare la modifica del comportamento della pipeline.

Sono disponibili molti utenti che si basano sulle variabili di impostazione usando il comando di registrazione nella pipeline. Con questa versione vengono apportate le modifiche seguenti per ridurre il rischio di usi indesiderati del setVariable comando.

• È stato aggiunto un nuovo costrutto per gli autori di attività. Includendo un frammento di codice come il seguente in task.json, un autore di attività può controllare se le variabili vengono impostate dall'attività.

{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}​ 

• Inoltre, stiamo aggiornando una serie di attività predefinite, ad esempio ssh, in modo che non possano essere sfruttate.

• Infine, è ora possibile usare costrutti YAML per controllare se un passaggio può impostare le variabili.

steps:
- script: echo hello
  target:
    settableVariables: none

steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

Generare un token senza restrizioni per le compilazioni fork

Gli utenti di GitHub Enterprise usano comunemente i fork per contribuire a un repository upstream. Quando Azure Pipelines compila contributi da un fork di un repository GitHub Enterprise, limita le autorizzazioni concesse al token di accesso al processo e non consente l'accesso ai segreti della pipeline da tali processi. Nella documentazione sono disponibili altre informazioni sulla sicurezza dei fork di compilazione.

Questo può essere più restrittivo rispetto a quello desiderato in tali ambienti chiusi, in cui gli utenti potrebbero comunque trarre vantaggio da un modello di collaborazione all'origine interna. Anche se è possibile configurare un'impostazione in una pipeline per rendere disponibili i segreti per i fork, non esiste alcuna impostazione per controllare l'ambito del token di accesso al processo. Con questa versione viene dato il controllo per generare un token di accesso al processo regolare anche per le compilazioni di fork.

È possibile modificare questa impostazione da Trigger nell'editor della pipeline. Prima di modificare questa impostazione, assicurarsi di comprendere completamente le implicazioni di sicurezza dell'abilitazione di questa configurazione.

Repos come risorsa protetta nelle pipeline YAML

È possibile organizzare il progetto Azure DevOps per ospitare molti sottoprogetti, ognuno con il proprio repository Git Azure DevOps e una o più pipeline. In questa struttura è possibile controllare quali pipeline possono accedere ai repository. Ad esempio, si supponga di avere due repository A e B nello stesso progetto e due pipeline X e Y che normalmente compilano questi repository. È possibile impedire l'accesso alla pipeline Y al repository A. In generale, si vuole che i collaboratori di A controllino quali pipeline vogliono fornire l'accesso.

Sebbene ciò sia stato parzialmente possibile con i repository e le pipeline Git di Azure, non è stata eseguita alcuna esperienza per la gestione. Questa funzionalità risolve tale gap. I repository Git di Azure possono ora essere considerati come risorse protette nelle pipeline YAML, proprio come le connessioni di servizio e i pool di agenti.

Come collaboratore del repository A, è possibile aggiungere controlli e autorizzazioni della pipeline al repository. A tale scopo, passare alle impostazioni del progetto, selezionare Repository e quindi il repository. Si noterà un nuovo menu denominato "Controlli", in cui è possibile configurare uno dei controlli nella casella o personalizzati sotto forma di funzioni di Azure.

Nella scheda "Sicurezza" è possibile gestire l'elenco delle pipeline che possono accedere al repository.

Ogni volta che una pipeline YAML usa un repository, l'infrastruttura di Azure Pipelines verifica e garantisce che tutti i controlli e le autorizzazioni siano soddisfatti.

Nota

Queste autorizzazioni e controlli sono applicabili solo alle pipeline YAML. Le pipeline classiche non riconoscono queste nuove funzionalità.

Autorizzazioni e controlli sui gruppi di variabili e sui file protetti

È possibile usare diversi tipi di risorse condivise nelle pipeline YAML. Gli esempi includono connessioni al servizio, gruppi di variabili, file sicuri, pool di agenti, ambienti o repository. Per proteggere una pipeline dall'accesso a una risorsa, il proprietario della risorsa può configurare le autorizzazioni e controllare tale risorsa. Ogni volta che una pipeline tenta di accedere alla risorsa, vengono valutate tutte le autorizzazioni e i controlli configurati. Queste protezioni sono state disponibili in connessioni, ambienti e pool di agenti per un po' di tempo. Sono stati aggiunti di recente ai repository. Con questa versione vengono aggiunte le stesse protezioni ai gruppi di variabili e ai file sicuri.

Per limitare l'accesso a un gruppo di variabili o a un file sicuro in un piccolo set di pipeline, usare la funzionalità Autorizzazioni Pipelines .

Per configurare controlli o approvazioni che devono essere valutati ogni volta che viene eseguita una pipeline, usare le approvazioni e i controlli per la funzionalità Libreria.

Modifiche nella creazione automatica degli ambienti

Quando si crea una pipeline YAML e si fa riferimento a un ambiente che non esiste, Azure Pipelines crea automaticamente l'ambiente. Questa creazione automatica può verificarsi nel contesto utente o nel contesto di sistema. Nei flussi seguenti Azure Pipelines conosce l'utente che esegue l'operazione:

• Usare la creazione guidata della pipeline YAML nell'esperienza Web di Azure Pipelines e fare riferimento a un ambiente che non è ancora stato creato.
• Aggiornare il file YAML usando l'editor Web di Azure Pipelines e salvare la pipeline dopo aver aggiunto un riferimento a un ambiente che non esiste. In ognuno dei casi precedenti, Azure Pipelines ha una chiara comprensione dell'utente che esegue l'operazione. Di conseguenza, crea l'ambiente e aggiunge l'utente al ruolo amministratore per l'ambiente. Questo utente dispone di tutte le autorizzazioni per gestire l'ambiente e/o per includere altri utenti in vari ruoli per la gestione dell'ambiente.

Nei flussi seguenti Azure Pipelines non dispone di informazioni sulla creazione dell'ambiente: aggiornare il file YAML usando un altro editor di codice esterno, aggiungere un riferimento a un ambiente che non esiste e quindi causare l'attivazione di una pipeline di integrazione continua. In questo caso, Azure Pipelines non conosce l'utente. In precedenza, questo caso è stato gestito aggiungendo tutti i collaboratori del progetto al ruolo di amministratore dell'ambiente. Qualsiasi membro del progetto potrebbe quindi modificare queste autorizzazioni e impedire ad altri utenti di accedere all'ambiente.

Sono stati ricevuti commenti e suggerimenti sulla concessione delle autorizzazioni di amministratore per un ambiente a tutti i membri di un progetto. Come abbiamo ascoltato il feedback, abbiamo sentito che non dovremmo creare automaticamente un ambiente se non è chiaro come chi l'utente esegue l'operazione. Con questa versione sono state apportate modifiche alla modalità di creazione automatica degli ambienti:

• In futuro, le esecuzioni della pipeline non creeranno automaticamente un ambiente se non esiste e se il contesto utente non è noto. In questi casi, la pipeline avrà esito negativo con un errore Di ambiente non trovato. È necessario pre-creare gli ambienti con la sicurezza corretta e controllare la configurazione prima di usarla in una pipeline.
• Le pipeline con contesto utente noto continueranno a creare automaticamente ambienti come in passato.
• Infine, si noti che la funzionalità per creare automaticamente un ambiente è stata aggiunta solo per semplificare il processo di introduzione ad Azure Pipelines. È stato progettato per gli scenari di test e non per gli scenari di produzione. È consigliabile creare sempre ambienti di produzione con le autorizzazioni e i controlli corretti e quindi usarli nelle pipeline.

Rimuovere il dialogo Insights dalla pipeline di compilazione

In base al feedback, la finestra di dialogo attività/pipeline Insights visualizzata durante l'esplorazione della pipeline di compilazione è stata rimossa per migliorare il flusso di lavoro. L'analisi della pipeline è ancora disponibile in modo che siano necessarie le informazioni dettagliate necessarie.

Supporto per le distribuzioni sequenziali anziché più recenti solo quando si usano controlli di blocco esclusivi

Nelle pipeline YAML i controlli vengono usati per controllare l'esecuzione delle fasi sulle risorse protette. Uno dei controlli comuni che è possibile usare è un controllo di blocco esclusivo. Questo controllo consente solo una singola esecuzione dalla pipeline di procedere. Quando più esecuzioni tentano di distribuire in un ambiente contemporaneamente, il controllo annulla tutte le esecuzioni precedenti e consente la distribuzione dell'esecuzione più recente.

L'annullamento delle esecuzioni precedenti è un approccio ottimale quando le versioni sono cumulative e contengono tutte le modifiche al codice delle esecuzioni precedenti. Esistono tuttavia alcune pipeline in cui le modifiche al codice non sono cumulative. Con questa nuova funzionalità, è possibile scegliere di consentire a tutte le esecuzioni di procedere e distribuire in sequenza in un ambiente oppure mantenere il comportamento precedente di annullare le esecuzioni precedenti e consentire solo l'ultima versione. È possibile specificare questo comportamento usando una nuova proprietà denominata lockBehavior nel file YAML della pipeline. Un valore di sequential implica che tutte le esecuzioni acquisiscono il blocco in sequenza alla risorsa protetta. Un valore di runLatest implica che solo l'esecuzione più recente acquisisce il blocco alla risorsa.

Per usare il controllo di blocco esclusivo con sequential le distribuzioni o runLatest, seguire questa procedura:

1. Abilitare il controllo di blocco esclusivo sull'ambiente (o su un'altra risorsa protetta).
2. Nel file YAML per la pipeline specificare una nuova proprietà denominata lockBehavior. Questa operazione può essere specificata per l'intera pipeline o per una determinata fase:

Impostare su una fase:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Impostare nella pipeline:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Se non si specifica un lockBehavioroggetto , si presuppone che sia runLatest.

Supporto per la versione di Quebec di ServiceNow

Azure Pipelines ha un'integrazione esistente con ServiceNow. L'integrazione si basa su un'app in ServiceNow e su un'estensione in Azure DevOps. Ora l'app è stata aggiornata per il funzionamento con la versione del Quebec di ServiceNow. Sia le pipeline classiche che YAML ora funzionano con Quebec. Per assicurarsi che questa integrazione funzioni, eseguire l'aggiornamento alla nuova versione dell'app (4.188.0) dall'archivio Service Now. Per altre informazioni, vedere Integrare con ServiceNow Change Management.

Nuove espressioni condizionali YAML

La scrittura di espressioni condizionali nei file YAML è semplice con l'uso di ${{ else }} ed ${{ elseif }} espressioni. Di seguito sono riportati esempi di come usare queste espressioni nei file di pipeline YAML.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux' }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Supporto per i caratteri jolly nei filtri di percorso

Le schede jolly possono essere usate quando si specificano rami di inclusione ed esclusione per trigger CI o PR in un file YAML della pipeline. Tuttavia, non possono essere usati quando si specificano filtri di percorso. Ad esempio, non è possibile includere tutti i percorsi corrispondenti src/app/**/myapp*a . Questo è stato sottolineato come un inconveniente da parte di diversi clienti. Questo aggiornamento riempie questo vuoto. È ora possibile usare caratteri jolly (**, *o ?) durante la specifica dei filtri di percorso.

La specifica predefinita dell'agente per le pipeline sarà Windows-2022

L'immagine windows-2022 è pronta per essere la versione predefinita per l'etichetta windows-latest negli agenti microsoft ospitati in Azure Pipelines. Fino ad ora, questa etichetta punta agli agenti windows-2019. Questa modifica verrà implementata in un periodo di diverse settimane a partire dal 17 gennaio. Si prevede di completare la migrazione entro marzo.

Azure Pipelines è supportato windows-2022 da settembre 2021. Abbiamo monitorato il feedback per migliorare la stabilità dell'immagine windows-2022 e ora siamo pronti per impostarlo come più recente.

L'immagine windows-2022 include Visual Studio 2022. Per un elenco completo delle differenze tra windows-2022 e windows-2019, visitare il problema di GitHub. Per un elenco completo del software installato nell'immagine, vedere qui.

La cartella della pipeline rinomina convalida le autorizzazioni

Le cartelle contenenti pipeline possono essere rinominate. La ridenominazione di una cartella avrà esito positivo solo se l'utente dispone delle autorizzazioni di modifica su almeno una pipeline contenuta nella cartella.

Pianificazione dell'aggiornamento del runtime di Pipelines Agent

Che cos'è l'agente della pipeline?

Azure DevOps Pipeline Agent è il prodotto software in esecuzione in un host della pipeline per eseguire processi di pipeline. Viene eseguito su agenti ospitati da Microsoft, agenti del set di scalabilità e agenti self-hosted. In quest'ultimo caso si installa manualmente. L'agente della pipeline è costituito da un listener e un ruolo di lavoro (implementato in .NET), il ruolo di lavoro esegue le attività implementate in Node o PowerShell e quindi ospita tali runtime.

Aggiornamento successivo a .NET 6 & deprecazione di Red Hat 6

Con la versione di .NET 6 è possibile sfruttare le nuove funzionalità multipiattaforma. In particolare, sarà possibile fornire compatibilità nativa per Apple Silicon e Windows Arm64. Di conseguenza, si prevede di passare a .NET 6 per l'agente pipeline (listener e worker) nei prossimi mesi.

A causa di un numero di vincoli che questo impone, il supporto di Red Hat Enterprise Linux 6 viene interrotto dall'agente 30 aprile 2022.

Aggiornamenti all'attività Copia file di Azure

Viene implementata una nuova versione dell'attività Copia file di Azure. Questa attività viene usata per copiare file in BLOB di archiviazione di Microsoft Azure o macchine virtuali . La nuova versione ha diversi aggiornamenti che sono stati spesso richiesti dalla community:

• La versione dello strumento AzCopy è stata aggiornata alla versione 10.12.2, che ha il supporto per i tipi di contenuto di file. Di conseguenza, quando si copia PDF, Excel, PPT o uno dei tipi mime supportati, il tipo di contenuto del file viene impostato correttamente.

• Con la nuova versione di AzCopy, è anche possibile configurare un'impostazione per pulire la destinazione quando il tipo di destinazione è BLOB di Azure. L'impostazione di questa opzione elimina tutte le cartelle/file nel contenitore. In alternativa, se viene fornito un prefisso BLOB, verranno eliminate tutte le cartelle/file in tale prefisso.

• La nuova versione dell'attività si basa sui moduli Az installati nell'agente anziché sui moduli AzureRM. In alcuni casi verrà rimosso un avviso non necessario quando si usa l'attività.

Le modifiche fanno parte di un aggiornamento della versione principale per questa attività. È necessario aggiornare in modo esplicito le pipeline per usare la nuova versione. È stata effettuata questa scelta per aggiornare la versione principale per garantire che non vengano interrotte le pipeline che dipendono ancora dai moduli azureRM.

Nuovi punti di estensione per la visualizzazione dettagli pipeline

Sono stati aggiunti due nuovi punti di estendibilità destinati alle estensioni. Questi punti di estendibilità consentono di aggiungere un pulsante personalizzato nell'intestazione della pipeline e un menu personalizzato in una cartella della pipeline:

• Pulsante personalizzato nell'intestazione della pipeline: ms.vss-build-web.pipelines-header-menu
• Menu personalizzato in una cartella della pipeline: ms.vss-build-web.pipelines-folder-menu

Per usare questi nuovi punti di estendibilità, aggiungere semplicemente un nuovo contributo destinato al file manifesto dell'estensione vss-extension.json Azure DevOps.

Ad esempio:

"contributions": [
        {
            "id": "pipelinesFolderContextMenuTestItem",
            "type": "ms.vss-web.action",
            "description": "Custom menu on a pipeline folder",
            "targets": [
                "ms.vss-build-web.pipelines-folder-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        },
        {
            "id": "pipelinesHeaderTestButton",
            "type": "ms.vss-web.action",
            "description": "Custom button in the pipeline header",
            "targets": [
                "ms.vss-build-web.pipelines-header-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        }
]

Il risultato sarà:

• Pulsante personalizzato nell'intestazione della pipeline

  

• Menu personalizzato in una cartella della pipeline

  

Miglioramento della migrazione a Azure DevOps Services

Quando si esegue un'importazione da Azure DevOps Server a Azure DevOps Services, è necessario considerare che Azure DevOps non supporta più le regole di conservazione per pipeline. Con questo aggiornamento, questi criteri sono stati rimossi quando si esegue la migrazione a Azure DevOps Services dall'Azure DevOps Server locale. Per altre informazioni sulla configurazione dei criteri di conservazione, vedere la documentazione sull'impostazione dei criteri di conservazione per compilazioni, versioni e test.

Miglioramento dell'API REST delle esecuzioni di pipeline

In precedenza, l'API REST Pipelines Runs restituisce solo il self repository. Con questo aggiornamento, l'API REST Pipelines Runs restituisce tutte le risorse del repository di una compilazione.

I modelli di pipeline YAML estesi possono ora essere passate informazioni di contesto per fasi, processi e distribuzioni

Con questo aggiornamento viene aggiunta una nuova templateContext proprietà per jobi componenti della pipeline , deploymente stage YAML che devono essere usati in combinazione con i modelli.

Ecco uno scenario per l'uso templateContextdi :

• Si usano modelli per ridurre la duplicazione del codice o per migliorare la sicurezza delle pipeline

• Il modello accetta come parametro un elenco di stages, jobso deployments

• Il modello elabora l'elenco di input ed esegue alcune trasformazioni in ognuna delle fasi, dei processi o delle distribuzioni. Ad esempio, imposta l'ambiente in cui viene eseguito ogni processo o aggiunge passaggi aggiuntivi per applicare la conformità

• L'elaborazione richiede il passaggio di informazioni aggiuntive dall'autore della pipeline nel modello per ogni fase, processo o distribuzione nell'elenco

Di seguito è descritto un esempio. Si supponga di creare una pipeline che esegue test end-to-end per la convalida delle richieste pull. L'obiettivo è testare solo un componente del sistema, ma, poiché si prevede di eseguire test end-to-end, è necessario un ambiente in cui sono disponibili più componenti del sistema ed è necessario specificarne il comportamento.

Ci si rende conto che altri team avranno esigenze simili, quindi si decide di estrarre i passaggi per configurare l'ambiente in un modello. Il codice è simile al seguente:

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

Ciò che il modello esegue, per ogni processo nel testSet parametro , imposta la risposta dei componenti del sistema specificati da ${{ testJob.templateContext.requiredComponents }} per restituire ${{ testJob.templateContext.expectedHTTPResponseCode }}.

È quindi possibile creare una pipeline personalizzata che si estende testing-template.yml come nell'esempio seguente.

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

Questa pipeline esegue due test, uno positivo e negativo. Entrambi i test richiedono che il dimensionsapi componente sia disponibile. Il positive_test processo prevede il dimensionsapi codice HTTP restituito 200, mentre negative_test prevede che restituisca il codice HTTP 500.

Supporto degli account del servizio gestito del gruppo come account del servizio agente

L'agente di Azure Pipelines supporta ora gli account del servizio gestito del gruppo negli agenti self-hosted in Windows.

Gli account del servizio gestito del gruppo offrono una gestione centralizzata delle password per gli account di dominio che fungono da account del servizio. L'agente di Azure Pipelines può riconoscere questo tipo di account in modo che non sia necessaria una password durante la configurazione:

.\config.cmd --url https://dev.azure.com/<Organization> `
             --auth pat --token <PAT> `
             --pool <AgentPool> `
             --agent <AgentName> --replace `
             --runAsService `
             --windowsLogonAccount <DOMAIN>\<gMSA>

Esecuzioni informative

Un'esecuzione informativa indica che Azure DevOps non è riuscito a recuperare il codice sorgente di una pipeline YAML. Tale esecuzione ha un aspetto simile al seguente.

Azure DevOps recupera il codice sorgente di una pipeline YAML in risposta a eventi esterni, ad esempio un commit push o in risposta a trigger interni, ad esempio, per verificare se sono presenti modifiche al codice e avviare o meno un'esecuzione pianificata. Quando questo passaggio ha esito negativo, il sistema crea un'esecuzione informativa. Queste esecuzioni vengono create solo se il codice della pipeline si trova in un repository GitHub o BitBucket.

Il recupero del codice YAML di una pipeline può non riuscire a causa di:

• Il provider di repository ha riscontrato un'interruzione del servizio
• Limitazione delle richieste
• Problemi di autenticazione
• Impossibile recuperare il contenuto del file con estensione yml della pipeline

Altre informazioni sulle esecuzioni informative.

La proprietà DELL'API retentionRules REST della definizione di compilazione è obsoleta

Nel tipo di risposta dell'API REST di definizione di BuildDefinition compilazione la retentionRules proprietà è ora contrassegnata come obsoleta, perché questa proprietà restituisce sempre un set vuoto.

Repos

Nuove pagine TFVC

Sono state aggiornate diverse pagine in Azure DevOps per usare una nuova piattaforma Web con l'obiettivo di rendere l'esperienza più coerente e più accessibile tra i vari servizi. Le pagine TFVC sono state aggiornate per l'uso della nuova piattaforma Web. Con questa versione, le nuove pagine TFVC sono disponibili a livello generale.

Disabilitare un repository

I clienti hanno spesso richiesto un modo per disabilitare un repository e impedire agli utenti di accedervi. Ad esempio, è possibile eseguire questa operazione quando:

• È stato trovato un segreto nel repository.
• Uno strumento di analisi di terze parti ha rilevato che un repository non è conforme.

In questi casi, è possibile disabilitare temporaneamente il repository mentre si lavora per risolvere il problema. Con questo aggiornamento, è possibile disabilitare un repository se si dispone delle autorizzazioni Elimina repository . Disabilitando un repository, è possibile:

• Può elencare il repository nell'elenco dei repository
• Impossibile leggere il contenuto del repository
• Impossibile aggiornare il contenuto del repository
• Visualizzare un messaggio che informa che il repository è stato disabilitato quando tenta di accedere al repository nell'interfaccia utente di Azure Repos

Dopo aver eseguito i passaggi di mitigazione necessari, gli utenti con l'autorizzazione Elimina repository possono riabilitare il repository. Per disabilitare o abilitare un repository, passare a Impostazioni progetto, selezionare Repository e quindi il repository specifico.

Configurare gli autori di rami per non ottenere le "autorizzazioni di gestione" nei rami

Quando si crea un nuovo ramo, si ottengono le "autorizzazioni di gestione" in tale ramo. Questa autorizzazione consente di modificare le autorizzazioni di altri utenti o di consentire ad altri utenti di contribuire a tale ramo. Ad esempio, un creatore di rami può usare questa autorizzazione per consentire a un altro utente esterno di apportare modifiche al codice. In alternativa, possono consentire a una pipeline (identità del servizio di compilazione) di modificare il codice in tale ramo. In determinati progetti con requisiti di conformità più elevati, gli utenti non devono essere in grado di apportare tali modifiche.

Con questo aggiornamento, è possibile configurare tutti i repository nel progetto team e limitare i creatori di rami a ottenere l'autorizzazione "Gestisci autorizzazioni". A tale scopo, passare alle impostazioni del progetto, selezionare Repository e quindi Impostazioni per tutti i repository o un repository specifico.

Questa impostazione è attivata per impostazione predefinita per simulare il comportamento esistente. Tuttavia, è possibile disattivarlo se si vuole usare questa nuova funzionalità di sicurezza.

Impedire agli utenti con fork di votare sulle richieste pull upstream

Con Azure Repos, gli utenti con l'autorizzazione "lettura" per un repository possono creare una copia tramite fork del repository e apportare modifiche nel fork. Per inviare una richiesta pull con le modifiche apportate all'upstream, gli utenti devono disporre dell'autorizzazione "contribuire alle richieste pull" nell'upstream. Tuttavia, questa autorizzazione determina anche chi può votare le richieste pull nel repository upstream. Di conseguenza, è possibile terminare in situazioni in cui un utente, che non è un collaboratore al repository, può inviare una richiesta pull e far sì che venga unito a seconda del modo in cui si configurano i criteri di ramo.

Nei progetti che promuovono un modello di origine interna, fork-and-contribute è un modello comune. Per proteggere e promuovere ulteriormente questo modello, stiamo modificando l'autorizzazione per votare una richiesta pull da "contribuire alle richieste pull" per "contribuire". Tuttavia, questa modifica non viene apportata per impostazione predefinita in tutti i progetti. È necessario acconsentire esplicitamente e selezionare un nuovo criterio nel repository, denominato "Strict Vote Mode" per cambiare questa autorizzazione. È consigliabile farlo se ci si basa su fork in Azure Repos.

Report

Raggruppa per tag disponibili nei widget del grafico

Il widget grafico Raggruppa per tag è ora disponibile per impostazione predefinita per tutti i clienti. Quando si usa il widget del grafico, è ora disponibile un'opzione per i tag. Gli utenti possono visualizzare le informazioni selezionando tutti i tag o un set di tag nel widget.

Visualizzare i tipi di elementi di lavoro personalizzati nel widget burndown

In precedenza, non era possibile visualizzare i tipi di elemento di lavoro personalizzati configurati nel widget burn-down e sommati o conteggiati da un campo personalizzato. Con questo aggiornamento è stato risolto questo problema e ora è possibile visualizzare i tipi di elementi di lavoro personalizzati nel widget burndown.

---

Commenti e suggerimenti

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

---

Inizio pagina