Note sulla versione di Azure DevOps Server 2022

---

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

---

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

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

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

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

---

Data di rilascio di Azure DevOps Server 2022 Update 0.1 Patch 5: 14 novembre 2023

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.

• Estendere l'elenco di caratteri consentiti per le attività di PowerShell per abilitare la convalida dei parametri degli argomenti delle attività della shell.
• Correzione di un problema che causava la persistenza delle modifiche alle connessioni al servizio dopo aver fatto clic sul pulsante Annulla.

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

È 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à "Analysis Owner" mostrava come 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 in modo da ignorare gli errori delle attività e pulire il numero di artefatti possibile.

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

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

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

Data di rilascio di Azure DevOps Server 2022 Update 0.1 Patch 2: 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à spoofing del server Azure DevOps.
• Correzione di un bug nelle chiamate SOAP in cui è possibile creare un'eccezione ArithmeticException per la risposta XML di metadati di grandi dimensioni.
• Implementazione delle modifiche apportate all'editor delle connessioni del servizio in modo che lo stato dell'endpoint venga scaricato in caso di chiusura del componente.
• È stato risolto un problema con i collegamenti relativi che non funzionano nei file markdown.
• È stato risolto un problema di prestazioni correlato al livello applicazione che richiede più tempo del normale all'avvio quando è definito un numero elevato di tag.
• È stato risolto 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.

Data di rilascio di Azure DevOps Server 2022 Update 0.1 Patch 1: 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à spoofing del server Azure DevOps.
• CVE-2023-21569: vulnerabilità spoofing del server Azure DevOps.
• 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.

Data di rilascio dell'aggiornamento 0.1 di Azure DevOps Server 2022: 9 maggio 2023

Azure DevOps Server 2022.0.1 è un rollup delle correzioni di bug. Include tutte le correzioni in Azure DevOps Server 2022.0.1 RC 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.

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

Azure DevOps Server 2022.0.1 RC è un rollup delle correzioni di bug. Include tutte le correzioni nelle patch di 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 viene visualizzato Succeeded(Operazione completata).
• Correzione del comando "tfx extension publish" con errore "The given key was not present in the dictionary" (La chiave specificata non era presente nel dizionario).
• È stata implementata una soluzione alternativa per risolvere l'errore durante l'accesso all'estensione Calendario del team.
• CVE-2023-21564: vulnerabilità di scripting tra siti di Azure DevOps Server
• CVE-2023-21553: vulnerabilità di esecuzione di codice remoto di Azure DevOps Server
• Aggiornamento delle attività di MSBuild e VSBuild per supportare Visual Studio 2022.
• Metodologia di aggiornamento del caricamento della riautenticazione per impedire il vettore di attacco XSS.
• Il proxy di Azure DevOps Server 2022 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 del pool di applicazioni di Azure DevOps Server dopo l'aggiornamento dell'impostazione correlata a SMTP in Azure DevOps Server Management Console.
• Le notifiche non vengono inviate per pat sette giorni prima della data di scadenza.

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

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

• CVE-2023-21565: vulnerabilità spoofing del server Azure DevOps.
• CVE-2023-21569: vulnerabilità spoofing del server Azure DevOps.
• 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.

Data di rilascio di Azure DevOps Server 2022 Patch 3: 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 del pool di applicazioni di Azure DevOps Server dopo l'aggiornamento dell'impostazione correlata a SMTP in Azure DevOps Server Management Console.
• 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 venivano mantenute 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 preferenza team, i membri del team non riceveranno le notifiche. Non è necessario espandere ulteriormente le identità nel team per controllare le preferenze dei membri.

Data di rilascio di Azure DevOps Server 2022 Patch 2: 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 di Azure DevOps Server
• Aggiornamento delle attività di MSBuild e VSBuild per supportare Visual Studio 2022.
• Metodologia di aggiornamento del caricamento della riautenticazione per evitare possibili vettori di attacco XSS.
• Il proxy di Azure DevOps Server 2022 segnala l'errore seguente: VS800069: questo servizio è disponibile solo in Azure DevOps locale.

Data di rilascio di Azure DevOps Server 2022 Patch 1: 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, è 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 viene visualizzato Succeeded(Operazione completata).
• Correzione del comando "tfx extension publish" con errore "The given key was not present in the dictionary" (La chiave specificata non era presente nel dizionario).
• È stata implementata una soluzione alternativa per risolvere l'errore durante l'accesso all'estensione Calendario del team.

Data di rilascio di Azure DevOps Server 2022: 6 dicembre 2022

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

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

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

Il supporto della chiave pubblica RSA è stato migliorato per supportare i tipi di chiave pubblica SHA2 oltre a SHA1 SSH-RSA supportato in precedenza.

I tipi di chiave pubblica supportati includono:

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

Azione necessaria 

Se è stata implementata la soluzione alternativa per abilitare SSH-RSA specificandola in modo esplicito nel .ssh/config1 file, sarà necessario rimuovere o PubkeyAcceptedTypesmodificarla per usare RSA-SHA2-256 o RSA-SHA2-512 o entrambi. È possibile trovare informazioni dettagliate sulle operazioni da eseguire se viene ancora richiesta la password e GIT_SSH_COMMAND="ssh -v" git fetch non viene visualizzato alcun algoritmo di firma reciproca nella documentazione qui.

Il supporto delle chiavi ellittiche non è ancora stato aggiunto e rimane una funzionalità molto richiesta nel backlog.

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

Riepilogo delle novità di Azure DevOps Server 2022

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

• Piani di recapito
• Visualizzare l'utente corretto 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:

• Bacheche
• Repos
• Pipeline
• 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 della sequenza temporale del piano
• Avanzamento del lavoro
• Rilevamento delle dipendenze

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

Ci sono due viste principali: condensato ed espanso

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

Ci sono due viste principali la vista condensata e la visualizzazione espansa. È anche possibile ingrandire e ridurre il piano facendo clic sulla lente di ingrandimento sul lato ight-hand del piano.

Ci sono due viste principali la vista condensata e la visualizzazione espansa. È anche possibile ingrandire e ridurre il piano facendo clic sulla lente di ingrandimento sul lato destro del piano.

• Vista condensata

  La visualizzazione ridotta mostra tutte le schede degli elementi di lavoro compresse , ovvero non vengono visualizzate tutte le informazioni sulla scheda. 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.

  Di seguito è riportato un esempio di alternanza tra le visualizzazioni condensate ed 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 mostrando la percentuale di completamento. Attualmente lo stato di avanzamento è determinato dal conteggio degli elementi di lavoro.

  Di seguito è riportato un esempio di piano che usa una visualizzazione espansa. Si notino le barre di stato e la percentuale di completamento.

  

Rilevamento delle dipendenze

Il rilevamento delle dipendenze si basa sui collegamenti predecessore 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 di rosso.

• Visualizzazione delle dipendenze

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

  

  

• Righe di dipendenza

  Le dipendenze tra gli elementi di lavoro vengono visualizzate con linee di direzione 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.

  

  Di seguito è riportato un esempio di elemento di lavoro con più dipendenze e funziona anche usando la visualizzazione ridotta.

  

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

  Ecco un esempio.

  

Applicazione di stili alle schede

Le schede possono ora essere stilite 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 di

• Dopo

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

Elementi rimossi nell'hub elementi di lavoro

L'hub degli elementi di lavoro è la posizione in cui visualizzare un elenco di elementi creati o assegnati all'utente. Offre diverse funzioni di filtro e pivot personalizzate per semplificare l'elenco degli elementi di lavoro. Uno dei principali reclami del pivot Assegnato a me è che visualizza gli 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 all'utente corrente nell'hub elementi di lavoro.

Visualizzare l'utente corretto nei collegamenti di commit

La sezione sviluppo in un elemento di lavoro mostra l'elenco dei commit e delle richieste pull pertinenti. È possibile visualizzare l'autore del commit o della richiesta pull insieme all'ora associata. Con questo aggiornamento è stato risolto un problema relativo all'avatar dell'autore visualizzato in modo non corretto 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 degli elementi di lavoro, anche dopo la rimozione dell'allegato 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.

Aggiunta del 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. I motivi specificano il motivo per cui l'elemento è passato da uno stato a un altro. Con questo aggiornamento è stato aggiunto un valore di motivo Will not fix 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. Altre informazioni su come definire, acquisire, valutare e gestire 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 compilazioni classiche e le pipeline YAML nelle impostazioni del progetto Azure DevOps. Le regole di conservazione per pipeline per le pipeline di compilazione classiche non sono più supportate. Anche se questo è l'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. Tutte le regole di conservazione per pipeline per pipeline classiche sono state rimosse in una versione futura.

Ciò significa che qualsiasi pipeline di compilazione classica usata per avere regole di conservazione per pipeline sarà governata 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 compilazioni 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 sull'impostazione dei 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 ottenere comandi di registrazione speciali ed esegue tali comandi. Il setVariable comando può essere usato per impostare una variabile o modificare una variabile definita in precedenza. Ciò può essere potenzialmente 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.

Molti utenti si basano sull'impostazione delle variabili 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, ad esempio il seguente in task.json, un autore di attività può controllare se le variabili sono 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. Per altre informazioni sulla sicurezza della creazione di fork, vedere la documentazione.

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

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

Repository come risorsa protetta nelle pipeline YAML

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

Sebbene ciò sia stato parzialmente possibile con i repository e le pipeline Git di Azure, non c'era 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 al servizio e i pool di agenti.

In qualità di 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 qualsiasi controllo nella casella o personalizzato 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.

Autorizzazioni e controlli sui gruppi di variabili e sui file sicuri

È possibile usare diversi tipi di risorse condivise nelle pipeline YAML. Ad esempio, le connessioni al servizio, i gruppi di variabili, i file protetti, i pool di agenti, gli ambienti o i 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 disponibili per un po' di tempo per connessioni, ambienti e pool di agenti del servizio. 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 a 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 la funzionalità Approvazioni e verifica la presenza di librerie .

Modifiche alla creazione automatica di 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 conoscenza chiara dell'utente che esegue l'operazione. Di conseguenza, crea l'ambiente e aggiunge l'utente al ruolo di 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 sull'utente che crea l'ambiente: si aggiorna il file YAML usando un altro editor di codice esterno, si aggiunge un riferimento a un ambiente che non esiste e quindi si attiva 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. Durante l'ascolto dei commenti e suggerimenti, abbiamo sentito che non dovremmo creare automaticamente un ambiente se non è chiaro a chi l'utente che 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 Environment non trovato. È necessario creare in precedenza gli ambienti con la sicurezza corretta e verificare la configurazione prima di usarla in una pipeline.
• Le pipeline con contesto utente noto continueranno a creare automaticamente gli ambienti esattamente 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 usarli nelle pipeline.

Rimuovere la finestra di dialogo Informazioni dettagliate dalla pipeline di compilazione

In base ai commenti e suggerimenti, la finestra di dialogo Informazioni dettagliate attività/pipeline visualizzata durante l'esplorazione della pipeline di compilazione è stata rimossa per migliorare il flusso di lavoro. L'analisi della pipeline è ancora disponibile in modo da avere le informazioni necessarie.

Supporto per 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 un'esecuzione singola dalla pipeline. Quando più esecuzioni tentano di eseguire la distribuzione 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 buon approccio 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 distribuirlo 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. Il valore sequential implica che tutte le esecuzioni acquisiscono il blocco in sequenza alla risorsa protetta. Un valore implica runLatest che solo l'esecuzione più recente acquisisce il blocco alla risorsa.

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

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

Impostata 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 oggetto lockBehavior, 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 un'estensione in Azure DevOps. L'app è stata aggiornata per lavorare con la versione Di ServiceNow in Quebec. Le pipeline classiche e YAML ora funzionano con Quebec. Per assicurarsi che questa integrazione funzioni, eseguire l'aggiornamento alla nuova versione dell'app (4.188.0) dall'archivio di Service Now. Per altre informazioni, vedere Integrare con ServiceNow Change Management.

Nuove espressioni condizionali YAML

La scrittura di espressioni condizionali nei file YAML è stata semplificata con l'uso di ${{ else }} espressioni e ${{ elseif }} . 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 caratteri jolly nei filtri di percorso

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

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

L'immagine windows-2022 è pronta per essere la versione predefinita per l'etichetta windows-latest negli agenti ospitati da Microsoft in Azure Pipelines. Fino ad ora, questa etichetta puntava 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 i commenti e suggerimenti 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 ridenominazione della cartella della pipeline 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 per almeno una pipeline contenuta nella cartella.

Pianificazione dell'aggiornamento del runtime di Pipelines Agent

Che cos'è l'agente pipeline?

L'agente della pipeline di Azure DevOps è il prodotto software eseguito in un host della pipeline per eseguire i processi della 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 pipeline è costituito da un listener e da 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 imminente alla deprecazione di .NET 6 & Red Hat 6

Con il rilascio di .NET 6 è possibile sfruttare le nuove funzionalità multipiattaforma. In particolare, saremo in grado di fornire la compatibilità nativa per Apple Silicon e Windows Arm64. Si prevede quindi di passare a .NET 6 per l'agente pipeline (listener e ruolo di lavoro) nei prossimi mesi.

A causa di una serie di vincoli imposti da questo problema, il supporto di Red Hat Enterprise Linux 6 viene interrotto dall'agente il 30 aprile 2022.

Aggiornamenti all'attività Copia file di Azure

È in fase di implementazione una nuova versione dell'attività Copia file di Azure. Questa attività viene usata per copiare file in BLOB o macchine virtuali di Archiviazione di Microsoft Azure. La nuova versione include diversi aggiornamenti che sono stati spesso richiesti dalla community:

• La versione dello strumento AzCopy è stata aggiornata alla versione 10.12.2, che supporta 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 comporta l'eliminazione di tutte le cartelle o i file nel contenitore. In alternativa, se viene specificato un prefisso BLOB, verranno eliminati tutti i file o le cartelle 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à, è sufficiente aggiungere un nuovo contributo destinato a tali punti nel 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

  

Migrazione migliorata ad Azure DevOps Services

Quando si esegue un'importazione da Azure DevOps Server ad 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 ad Azure DevOps Services dal server Azure DevOps locale. Per altre informazioni sulla configurazione dei criteri di conservazione, vedere la documentazione sull'impostazione dei criteri di conservazione per build, versioni e test.

Miglioramento dell'API REST per le esecuzioni di pipeline

In precedenza, l'API REST Pipelines Esegue ha restituito 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 destinati all'uso in combinazione con i modelli.

Ecco uno scenario per l'uso di templateContext:

• 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 un solo 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, un positivo e uno 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 di gruppo negli agenti self-hosted in Windows.

Gli account del servizio gestito del gruppo forniscono 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. Un'esecuzione di questo tipo è simile alla seguente.

Azure DevOps recupera il codice sorgente di una pipeline YAML in risposta a eventi esterni, ad esempio un commit sottoposto a 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:

• Si è verificato un'interruzione del provider di repository
• Limitazione delle richieste
• Problemi di autenticazione
• Impossibile recuperare il contenuto del file di .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 nei vari servizi. Le pagine TFVC sono state aggiornate per usare la nuova piattaforma Web. Con questa versione, stiamo rendendo disponibili le nuove pagine TFVC 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
• Viene visualizzato un messaggio che informa che il repository è stato disabilitato quando prova ad accedere al repository nell'interfaccia utente di Azure Repos

Dopo aver eseguito i passaggi di mitigazione necessari, gli utenti con 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 dei rami in modo che non ottengano "autorizzazioni di gestione" per i rispettivi 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 alcuni 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 di fork di votare in merito alle rispettive richieste pull upstream

Con Azure Repos, gli utenti con autorizzazione di "lettura" per un repository possono creare un fork del repository e apportare modifiche nel fork. Per inviare una richiesta pull con le modifiche apportate all'upstream, gli utenti devono "contribuire alle richieste pull" per l'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 della modalità di configurazione dei 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.

Creazione di 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 elementi di lavoro personalizzati configurati nel widget di burn-down e sommati o conteggiati da un campo personalizzato. Con questo aggiornamento, questo problema è stato risolto e ora è possibile visualizzare i tipi di elementi di lavoro personalizzati nel widget burndown.

---

Commenti

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

---

In alto