Note sulla versione di Azure DevOpsServer 2020 Update 1

  • Articolo

| Developer Community Requisiti | disistema Condizioni di licenza DevOps | Blog | SHA-1 Hashes

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

Per altre informazioni sull'installazione o l'aggiornamento di una distribuzione Azure DevOps Server, vedere Requisiti Azure DevOps Server. Per scaricare i prodotti Azure DevOps, visitare la pagina download Azure DevOps Server.

L'aggiornamento diretto a Azure DevOps Server 2020 è supportato da Azure DevOps Server 2019 o Team Foundation Server 2015 o versione successiva. Se la distribuzione TFS è in TFS 2010 o versioni precedenti, è necessario eseguire alcuni passaggi provvisori prima di eseguire l'aggiornamento a Azure DevOps Server 2019. Per altre informazioni, vedere Installare e configurare Azure DevOps in locale.

Aggiornamento sicuro da Azure DevOps Server 2019 a Azure DevOps Server 2020

Azure DevOps Server 2020 introduce un nuovo modello di conservazione di esecuzione della pipeline (build) che funziona in base alle impostazioni a livello di progetto.

Azure DevOps Server 2020 gestisce in modo diverso la conservazione della compilazione, in base ai criteri di conservazione a livello di pipeline. Alcune configurazioni dei criteri comportano l'eliminazione delle esecuzioni della pipeline dopo l'aggiornamento. Le esecuzioni della pipeline mantenute manualmente o mantenute da una versione non verranno eliminate dopo l'aggiornamento.

Per altre informazioni su come eseguire l'aggiornamento sicuro da Azure DevOps Server 2019 a Azure DevOps Server 2020, leggere il post di blog.

Azure DevOps Server 2020 Update 1.2 Patch 13 Release Date: 12 marzo 2024

File Hash SHA-256
devops2020.1.2patch13.exe 55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6

È stata rilasciata la patch 13 per Azure DevOps Server 2020 Update 1.2 che include correzioni per quanto segue:

  • È stato risolto un problema a causa del quale il server proxy si è arrestato dopo l'installazione di Patch 12.

Azure DevOps Server 2020 Update 1.2 Patch 12 Release Date: 13 febbraio 2024

File Hash SHA-256
devops2020.1.2patch12.exe C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

È stata rilasciata la patch 12 per Azure DevOps Server 2020 Update 1.2 che include correzioni per quanto segue:

  • Correzione di un bug in cui lo spazio su disco usato dalla cartella della cache proxy è stato calcolato in modo errato e la cartella non è stata pulita correttamente.
  • CVE-2024-20667: Azure DevOps Server vulnerabilità di esecuzione del codice remoto.

Azure DevOps Server 2020 Update 1.2 Patch 11 Data di rilascio: 12 dicembre 2023

File Hash SHA-256
devops2020.1.2patch11.exe C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

È stata rilasciata la patch 11 per Azure DevOps Server 2020 Update 1.2 che include correzioni per quanto segue:

  • Correzione di un bug in cui l'ereditarietà della sicurezza di approvazione della distribuzione non funzionava nelle fasi delle pipeline.

Azure DevOps Server 2020 Update 1.2 Patch 10 Data di rilascio: 14 novembre 2023

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

  • Estensione dell'elenco di caratteri consentiti delle attività di PowerShell per Abilitare la convalida dei parametri delle attività della shell.

Nota

Per implementare le correzioni per questa patch, è necessario seguire una serie di passaggi per aggiornare manualmente le attività.

Installare patch

Importante

Sono stati rilasciati aggiornamenti all'agente di Azure Pipelines con patch 8 rilasciati il 12 settembre 2023. Se gli aggiornamenti dell'agente non sono stati installati come descritto nelle note sulla versione per Patch 8, è consigliabile installare questi aggiornamenti prima di installare Patch 10. La nuova versione dell'agente dopo l'installazione di Patch 8 sarà 3.225.0.

Configurare TFX

  1. Seguire la procedura descritta nella documentazione di caricamento della raccolta di progetti per installare e accedere con tfx-cli.

Aggiornare le attività con TFX

File Hash SHA-256
Tasks20231103.zip 389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5
  1. Scaricare ed estrarre Tasks20231103.zip.
  2. Modificare la directory nei file estratti.
  3. Eseguire i comandi seguenti per caricare le attività:
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip

Requisiti della pipeline

Per usare il nuovo comportamento, una variabile deve essere impostata AZP_75787_ENABLE_NEW_LOGIC = true nelle pipeline che usano le attività interessate.

  • In versione classica:

    Definire la variabile nella scheda variabile nella pipeline.

  • Esempio YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true

Azure DevOps Server 2020 Update 1.2 Patch 9 Data di rilascio: 10 ottobre 2023

Importante

Sono stati rilasciati aggiornamenti all'agente di Azure Pipelines con patch 8 rilasciati il 12 settembre 2023. Se gli aggiornamenti dell'agente non sono stati installati come descritto nelle note sulla versione per Patch 8, è consigliabile installare questi aggiornamenti prima di installare Patch 9. La nuova versione dell'agente dopo l'installazione di Patch 8 sarà 3.225.0.

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

  • Correzione di un bug in cui l'identità "Analysis Owner" viene visualizzata come Identità inattiva nei computer di aggiornamento delle patch.

Azure DevOps Server 2020 Update 1.2 Patch 8 Data di rilascio: 12 settembre 2023

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

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

Importante

Distribuire la patch in un ambiente di test e assicurarsi che le pipeline dell'ambiente funzionino come previsto prima di applicare la correzione alla produzione.

Nota

Per implementare le correzioni per questa patch, è necessario seguire una serie di passaggi per aggiornare manualmente l'agente e le attività.

Installare patch

  1. Scaricare e installare Azure DevOps Server 2020 Update 1.2 patch 8.

Aggiornare l'agente di Azure Pipelines

  1. Scaricare l'agente da: - https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 Agent_20230825.zip
  2. Usare i passaggi descritti nella documentazione degli agenti Windows self-hosted per distribuire l'agente.  

Nota

Il AZP_AGENT_DOWNGRADE_DISABLED deve essere impostato su "true" per impedire che l'agente venga sottoposto a downgrade. In Windows, il comando seguente può essere usato in un prompt dei comandi amministrativi, seguito da un riavvio. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Configurare TFX

  1. Seguire la procedura descritta nella documentazione di caricamento della raccolta di progetti per installare e accedere con tfx-cli.

Aggiornare le attività con TFX

  1. Scaricare ed estrarre Tasks_20230825.zip.
  2. Modificare la directory nei file estratti.
  3. Eseguire i comandi seguenti per caricare le attività:
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip

Requisiti della pipeline

Per usare il nuovo comportamento, una variabile deve essere impostata AZP_75787_ENABLE_NEW_LOGIC = true nelle pipeline che usano le attività interessate.

  • In versione classica:

    Definire la variabile nella scheda variabile nella pipeline.

  • Esempio YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true

Azure DevOps Server 2020 Update 1.2 Patch 7 Data di rilascio: 8 agosto 2023

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

  • CVE-2023-36869: vulnerabilità di spoofing Azure DevOps Server.
  • Aggiornare il servizio SSH per supportare SHA2-256 e SHA2-512. Se si dispone di file di configurazione SSH hardcoded per l'uso di RSA, è consigliabile eseguire l'aggiornamento a SHA2 o rimuovere la voce.
  • È stato risolto un problema con i collegamenti relativi che non funzionano nei file markdown.
  • Correzione di un bug con spostamento dei commenti in una pagina di commit.
  • 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 2020 Update 1.2 Patch 6 Data di rilascio: 13 giugno 2023

È stata rilasciata una patch per Azure DevOps Server 2020 Update 1.2 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 che interferisce con il push dei pacchetti durante l'aggiornamento da 2018 o versioni precedenti.
  • 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 2020 Update 1.2 Patch 5 Data di rilascio: 14 febbraio 2023

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

  • CVE-2023-21553: vulnerabilità di esecuzione del codice remoto Azure DevOps Server
  • Correzione del problema di accessibilità degli scaffali tramite l'interfaccia utente Web
  • I clienti devono riavviare il 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.

Azure DevOps Server 2020 Update 1.2 Patch 4 Data di rilascio: 13 dicembre 2022

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

  • Correzione della visualizzazione di caratteri speciali in IdentityPicker.

Gif per demo personaggi speciali in IndetityPicker.

  • 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.

Azure DevOps Server 2020 Update 1.2 Patch 3 Data di rilascio: 18 ottobre 2022

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

  • Risolvere il problema relativo alla mancata visualizzazione delle identità di Active Directory appena aggiunte nei selettore identità della finestra di dialogo di sicurezza.
  • Consente di risolvere un problema relativo al filtro Del gruppo richiesto dal membro del gruppo nelle impostazioni di webhook.
  • Correzione dell'errore di compilazione del check-in controllato quando le impostazioni organizzazione per la pipeline avevano l'ambito di autorizzazione del processo configurato come Limitare l'ambito di autorizzazione del processo al progetto corrente per le pipeline non di rilascio.
  • Correzione del recupero del token di accesso da Azure quando si stabilisce una connessione al servizio dietro il proxy autenticato.

Azure DevOps Server 2020 Update 1.2 Patch 2 Data di rilascio: 9 agosto 2022

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

  • Correggere l'errore relativo al valore identity durante l'assegnazione di un elemento di lavoro a un'identità visualizzata in domini diversi.

Azure DevOps Server 2020 Update 1.2 Patch 1 Data di rilascio: 12 luglio 2022

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

  • Nelle API Esecuzioni di test il token di continuazione restituito è maggiore del valore "maxLastUpdatedDate" specificato.

Azure DevOps Server 2020 Update 1.2 Data di rilascio: 17 maggio 2022

Azure DevOps Server 2020 Update 1.2 è un rollup di correzioni di bug. È possibile installare direttamente Azure DevOps Server 2020 Update 1.2 o eseguire l'aggiornamento da Azure DevOps Server 2020 o Team Foundation Server 2013 o versione successiva.

Nota

Lo strumento di migrazione dei dati sarà disponibile per Azure DevOps Server 2020 Update 1.2 circa tre settimane dopo questa versione. È possibile visualizzare l'elenco delle versioni attualmente supportate per l'importazione qui.

Questa versione include correzioni per quanto segue:

  • Azure DevOps Server 2020.1.2 disabilita il nuovo modello di conservazione (introdotto in Azure DevOps Server 2020), per evitare la perdita di esecuzioni di pipeline (compilazioni). Ciò significa che il sistema:

    • Creare lease per le build 3 più recenti generate durante l'esecuzione di Server 2020
    • Per le pipeline YAML e le pipeline classiche senza criteri di conservazione per pipeline, le compilazioni verranno mantenute in base alle impostazioni di conservazione massime a livello di raccolta
    • Per le pipeline classiche con criteri di conservazione personalizzati per pipeline, le compilazioni verranno mantenute in base ai criteri di conservazione specifici della pipeline
    • Le compilazioni con lease non vengono conteggiati per l'impostazione Minima da mantenere

  • I collegamenti a set di modifiche e commenti degli scaffali non venivano reindirizzati correttamente. Quando i commenti sono stati aggiunti ai file nei set di modifiche o negli scaffali, la selezione di tali commenti non reindirizzava alla posizione corretta nella visualizzazione file.

  • Impossibile ignorare la coda di compilazione usando il pulsante "Esegui successivo". In precedenza, il pulsante "Esegui successivo" era abilitato solo per gli amministratori della raccolta di progetti.

  • Revocare tutti i token di accesso personale dopo che l'account Active Directory di un utente è disabilitato.

Azure DevOps Server 2020.1.1 Patch 4 Data di rilascio: 26 gennaio 2022

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

  • Email le notifiche non sono state inviate quando si usa il @mention controllo in un elemento di lavoro.
  • L'indirizzo di posta elettronica preferito non è stato aggiornato nel profilo utente. Ciò ha comportato l'invio di messaggi di posta elettronica all'indirizzo di posta elettronica precedente.
  • Intestazione non visualizzata nella pagina Riepilogo progetto. L'intestazione è stata visualizzata per alcuni millisecondi e quindi è scomparsa.
  • Miglioramento della sincronizzazione utente di Active Directory.
  • È stata risolta la vulnerabilità di Elasticsearch rimuovendo la classe jndilookup dai file binari log4j.

Procedura di installazione

  1. Aggiornare il server con la patch 4.
  2. Controllare il valore del Registro di sistema in HKLM:\Software\Elasticsearch\Version. Se il valore del Registro di sistema non è presente, aggiungere un valore stringa e impostare Version su 5.4.1 (Name = Version, Value = 5.4.1).
  3. Eseguire il comando PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update update come specificato nel file leggimi. Può restituire un avviso simile a: Impossibile connettersi al server remoto. Non chiudere la finestra, perché l'aggiornamento esegue nuovi tentativi fino al completamento.

Nota

Se Azure DevOps Server e Elasticsearch sono installati in computer diversi, seguire questa procedura.

  1. Aggiornare il server con la patch 4.
  2. Controllare il valore del Registro di sistema in HKLM:\Software\Elasticsearch\Version. Se il valore del Registro di sistema non è presente, aggiungere un valore stringa e impostare Version su 5.4.1 (Name = Version, Value = 5.4.1).
  3. Copiare il contenuto della cartella denominata zip, che si trova nella C:\Program Files\{TFS Version Folder}\Search\zip cartella dei file remoti di Elasticsearch.
  4. Eseguire Configure-TFSSearch.ps1 -Operation update nel computer del server Elasticsearch.

HASH SHA-256: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Azure DevOps Server 2020.1.1 Patch 3 Data di rilascio: 15 dicembre 2021

La patch 3 per Azure DevOps Server 2020.1.1 include correzioni per quanto segue.

  • Correzione della macro dell'elemento di lavoro per le query con "Contiene parole". In precedenza, le query restituivano risultati non corretti per i valori che conteneva un'interruzione di riga.
  • Aumentare i limiti per la lunghezza del carattere della versione del pacchetto Maven.
  • Problema di localizzazione per gli stati di layout degli elementi di lavoro personalizzati.
  • Problema di localizzazione nel modello di notifica tramite posta elettronica.
  • Problema con la valutazione delle regole NOTSAMEAS quando sono state definite più regole NOTSAMEAS per un campo.

Azure DevOps Server 2020.1.1 Patch 2 Data di rilascio: 26 ottobre 2021

La patch 2 per Azure DevOps Server 2020.1.1 include correzioni per quanto segue.

  • In precedenza, Azure DevOps Server poteva creare connessioni solo a GitHub Enterprise Server. Con questa patch, gli amministratori del progetto possono creare connessioni tra Azure DevOps Server e repository in GitHub.com. È possibile trovare questa impostazione nella pagina Connessioni GitHub in Impostazioni progetto.
  • Risolvere il problema con il widget Piano di test. Il report sull'esecuzione del test mostrava un utente non corretto nei risultati.
  • Correzione del problema relativo al mancato caricamento della pagina di riepilogo della panoramica del progetto.
  • Consente di risolvere il problema relativo al mancato invio dei messaggi di posta elettronica per confermare l'aggiornamento del prodotto.

Azure DevOps Server 2020.1.1 Patch 1 Data di rilascio: 14 settembre 2021

La patch 1 per Azure DevOps Server 2020.1.1 include correzioni per quanto segue.

  • Correzione dell'errore di download/caricamento degli artefatti.
  • Risolvere il problema relativo ai dati dei risultati dei test incoerenti.

Azure DevOps Server 2020 Update 1.1 Data di rilascio: 17 agosto 2021

Azure DevOps Server 2020 Update 1.1 è un roll up delle correzioni di bug. È possibile installare direttamente Azure DevOps Server 2020 Update 1.1 o aggiornare da Azure DevOps Server 2020 o Team Foundation Server 2013 o versione successiva.

Nota

Lo strumento di migrazione dei dati sarà disponibile per Azure DevOps Server 2020 Update 1.1 circa tre settimane dopo questa versione. È possibile visualizzare l'elenco delle versioni attualmente supportate per l'importazione qui.

Questa versione include correzioni per i bug seguenti:

Azure Boards

  • Il collegamento ipertestuale "Visualizza elemento di lavoro" nei messaggi di posta elettronica di notifica non usa l'URL pubblico.

Azure Repos

  • Le caselle di controllo Ereditarietà dei tipi di unione limitate vengono visualizzate per abilitare la modifica dei tipi di unione limite dopo l'impostazione dei criteri di ripetizione incrociata.

Azure Pipelines

  • Quando si modifica l'impostazione per l'aggiornamento dell'agente, le impostazioni non vengono propagate ad altri livelli di applicazione nell'ambiente.

Generale

  • Correzione dell'ortografia nella configurazione guidata del server.
  • Maggiore dimensione del pacchetto di estensione e consentire di modificare le dimensioni nel Registro di sistema.

Azure Test Plans

  • Impossibile tornare ai risultati dei test dopo aver eseguito il hitback dalla cronologia alla pagina di riepilogo.

Azure DevOps Server 2020.1 Data di rilascio patch 2: 10 agosto 2021

È stata rilasciata una patch per Azure DevOps Server 2020.1 che corregge quanto segue.

  • Correzione dell'errore dell'interfaccia utente della definizione di compilazione.
  • Modifica della cronologia di esplorazione per visualizzare i file anziché il repository radice.

data di rilascio Azure DevOps Server 2020.1 Patch 1: 15 giugno 2021

È stata rilasciata una patch per Azure DevOps Server 2020.1 che corregge quanto segue.

  • Proteggere i cookie usati nei flussi di autorizzazione che asseriscono SameSite=None.

  • Risolvere il problema relativo all'SDK notifiche. In precedenza, le sottoscrizioni delle notifiche che usano il filtro Percorso area non venivano analizzate correttamente.

data di rilascio Azure DevOps Server 2020.1 RTW: 25 maggio 2021

Riepilogo delle novità in Azure DevOps Server 2020.1 RTW

Azure DevOps Server 2020.1 RTW è un roll up delle correzioni di bug. Include tutte le funzionalità del Azure DevOps Server 2020.1 RC2 rilasciate in precedenza. Azure DevOps Server 2020.1 RTW è un roll up delle correzioni di bug. È possibile installare direttamente Azure DevOps Server 2020.1 o l'aggiornamento da Azure DevOps Server 2020, 2019 o Team Foundation Server 2015 o versione successiva.

Nota

Lo strumento di migrazione dei dati sarà disponibile per Azure DevOps Server 2020 Update 1 circa tre settimane dopo questa versione. È possibile visualizzare l'elenco delle versioni attualmente supportate per l'importazione qui.

Azure DevOps Server 2020.1 RC2 Data di rilascio: 13 aprile 2021

Riepilogo delle novità di Azure DevOps Server 2020.1 RC2

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

data di rilascio Azure DevOps Server 2020.1 RC1: 23 marzo 2021

Riepilogo delle novità in Azure DevOps Server 2020.1 RC1

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

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

Boards

Regole di restrizione della transizione dello stato

Continuiamo a chiudere il divario di parità delle funzionalità tra XML ospitato e il modello di processo ereditato. Questa nuova regola di tipo elemento di lavoro consente di limitare lo spostamento degli elementi di lavoro da uno stato a un altro. Ad esempio, è possibile limitare i bug da Nuovo a Risolto. Devono invece passare da Nuovo - Attivo ->> Risolto

immagine

È anche possibile creare una regola per limitare le transizioni di stato in base all'appartenenza al gruppo. Ad esempio, solo gli utenti del gruppo "Approvatori" possono spostare le storie utente da Nuovo -> Approvato.

Copiare l'elemento di lavoro per copiare elementi figlio

Una delle funzionalità più richieste per Azure Boards è la possibilità di copiare un elemento di lavoro che copia anche gli elementi di lavoro figlio. È stata aggiunta una nuova opzione a "Includi elementi di lavoro figlio" nella finestra di dialogo copia elemento di lavoro. Se selezionata, questa opzione copia l'elemento di lavoro e copia tutti gli elementi di lavoro figlio (fino a 100).

Questa pagina mostra la nuova opzione in Azure Boards includere elementi di lavoro figlio in un elemento di lavoro copiato.

Regole migliorate per i campi attivati e risolti

Fino ad ora, le regole per attivato by, data attivata, risolta by e data risolta sono state un mistero. Sono impostati solo per i tipi di elemento di lavoro di sistema e sono specifici del valore di stato "Active" e "Resolved". La logica è stata modificata in modo che queste regole non siano più per uno stato specifico. Vengono invece attivati dalla categoria (categoria di stato) in cui risiede lo stato. Ad esempio, si supponga di avere uno stato personalizzato di "Needs Testing" nella categoria Risolta. Quando l'elemento di lavoro cambia da "Active" a "Needs Testing", vengono attivate le regole Data risolte e risolte .

Ciò consente ai clienti di creare tutti i valori di stato personalizzati e di generare comunque i campi Attivati per, Data attivata, Risolti per e Data risolta , senza dover usare regole personalizzate.

Gli stakeholder possono spostare elementi di lavoro tra colonne di scheda

Gli stakeholder sono sempre stati in grado di modificare lo stato degli elementi di lavoro. Ma quando passano alla scheda Kanban, non sono in grado di spostare gli elementi di lavoro da una colonna a un'altra. Gli stakeholder dovranno invece aprire ogni elemento di lavoro, uno alla volta e aggiornare il valore dello stato. Questo è stato un punto di dolore per i clienti e siamo felici di annunciare che è ora possibile spostare elementi di lavoro tra colonne di scheda.

Tipi di elementi di lavoro di sistema nei backlog e nelle schede

È ora possibile aggiungere un tipo di elemento di lavoro di sistema al livello di backlog di scelta. Storicamente questi tipi di elemento di lavoro sono stati disponibili solo dalle query.

Processo Tipo di elemento di lavoro
Agile Problema
Scrum Impedimento
CMMI Richiesta di modifica
Problema
Verifica
Rischio

L'aggiunta di un tipo di elemento di lavoro di sistema a un livello backlog è semplice. È sufficiente passare al processo personalizzato e fare clic sulla scheda Livelli di backlog. Selezionare il livello di backlog scelto (ad esempio: Requisiti Backlog) e scegliere l'opzione modifica. Aggiungere quindi il tipo di elemento di lavoro.

Backlog

Azure Boards limite di repository dell'app GitHub generato

Il limite di repository per l'applicazione Azure Boards nel marketplace GitHub è stato aumentato da 100 a 250.

Personalizzare lo stato dell'elemento di lavoro quando viene unita la richiesta pull

Non tutti i flussi di lavoro sono uguali. Alcuni clienti vogliono chiudere gli elementi di lavoro correlati al completamento di una richiesta pull. Altri vogliono impostare gli elementi di lavoro su un altro stato da convalidare prima della chiusura. Dovremmo permettere a entrambi.

È disponibile una nuova funzionalità che consente di impostare gli elementi di lavoro sullo stato desiderato quando la richiesta pull viene unita e completata. A tale scopo, si analizza la descrizione della richiesta pull e si cerca il valore di stato seguito dal #mention degli elementi di lavoro. In questo esempio si impostano due storie utente su Risolte e si chiudeno due attività.

stato dell'elemento di lavoro

È ora possibile tenere traccia facilmente delle dipendenze di compilazione tra il progetto semplicemente collegando l'elemento di lavoro a una compilazione, Trovato in compilazione o Integrato nella compilazione.

collegare elementi di lavoro

Modifica della descrizione (testo della Guida) nei campi di sistema

È sempre stato possibile modificare la descrizione dei campi personalizzati. Tuttavia, per i campi di sistema come priorità, gravità e attività, la descrizione non è modificabile. Si tratta di un divario di funzionalità tra l'XML ospitato e ereditato che impediva ad alcuni clienti di eseguire la migrazione al modello ereditato. È ora possibile modificare la descrizione nei campi di sistema. Il valore modificato avrà effetto solo sul campo nel processo e sul tipo di elemento di lavoro. Ciò offre la flessibilità necessaria per avere descrizioni diverse per lo stesso campo in tipi di elementi di lavoro diversi.

modifica descrizione

Personalizzare lo stato dell'elemento di lavoro quando viene unita la richiesta pull

Le richieste pull spesso fanno riferimento a più elementi di lavoro. Quando si crea o si aggiorna una richiesta pull, è possibile chiudere alcuni di essi, risolverli e mantenere aperto il resto. A tale scopo, è ora possibile usare commenti come quelli illustrati nella figura seguente. Per altri dettagli, vedere la documentazione.

Personalizzare lo stato

Campo padre nella scheda attività

A causa della richiesta comune, è ora possibile aggiungere il campo Padre alle schede figlio e padre nella Scheda attività.

Scheda attività campo padre

Rimozione della regola "Assegnata a" nel tipo di elemento di lavoro Bug

Esistono diverse regole di sistema nascoste in tutti i diversi tipi di elementi di lavoro in Agile, Scrum e CMMI. Queste norme esistono da oltre un decennio e hanno in genere funzionato bene senza reclami. Tuttavia, ci sono un paio di regole che hanno esaurito il loro benvenuto. Una regola in particolare ha causato un sacco di dolore per i clienti nuovi ed esistenti e abbiamo deciso che è stato il momento di rimuoverlo. Questa regola esiste nel tipo di elemento di lavoro Bug nel processo Agile.

"Impostare il valore Assegnato su Creato da quando lo stato viene modificato in Risolto"

Abbiamo ricevuto molti commenti e suggerimenti su questa regola. In risposta, questa regola è stata rimossa dal tipo di elemento di lavoro Bug nel processo Agile. Questa modifica influirà su ogni progetto usando un processo Agile ereditato ereditato o un processo Agile ereditato personalizzato. Per i clienti che amano e dipendono da questa regola corrente, vedere il post di blog sui passaggi che è possibile eseguire per aggiungere nuovamente la regola in usando regole personalizzate.

Elementi rimossi nella pagina Elementi di lavoro

La pagina Elementi di lavoro è un ottimo posto per trovare rapidamente gli elementi creati o assegnati all'utente, tra le altre cose. Fornisce diversi pivot e filtri personalizzati. Uno dei principali reclami per il pivot "Assegnato a me" è che visualizza elementi di lavoro rimossi (ovvero gli elementi di lavoro nello stato Rimosso). E siamo d'accordo! Gli elementi rimossi sono operazioni che non sono più di valore e quindi sono stati rimossi dal backlog, quindi non è utile includerlo in questa visualizzazione.

È ora possibile nascondere tutti gli elementi rimossi dal pivot Assegnato a me nella pagina Elementi di lavoro.

Repos

Preferenza nome ramo predefinita

Azure Repos ora offre un nome di ramo predefinito personalizzabile per Git. Nelle impostazioni del repository è possibile scegliere qualsiasi nome di ramo legale da usare quando viene inizializzato un repository. Azure Repos ha sempre supportato la modifica del nome del ramo predefinito per un repository esistente. Per altri dettagli, vedere Gestire i rami .

 default-branch-name

Nota: se non si abilita questa funzionalità, i repository verranno inizializzati con il nome predefinito di Azure Repos. Al momento, l'impostazione predefinita è master. Per rispettare l'impegno di Microsoft e le richieste dei clienti per il linguaggio inclusivo, verrà aggiunto ai peer del settore per cambiare questa impostazione predefinita come principale. Questo cambiamento si verificherà più tardi quest'estate. Se si vuole continuare a usare master, è necessario attivare questa funzionalità ora e impostarla su master.

Impostazione a livello di organizzazione per il ramo predefinito

È ora disponibile un'impostazione a livello di raccolta per il nome del ramo iniziale preferito per i nuovi repository. Se un progetto non ha scelto un nome di ramo iniziale, verrà usata questa impostazione a livello di organizzazione. Se non è stato specificato il nome del ramo iniziale nelle impostazioni dell'organizzazione o nelle impostazioni del progetto, i nuovi repository useranno un'impostazione predefinita definita da Azure DevOps.

Impostazione del ramo per il livello dell'organizzazione

Aggiungere un nuovo ambito di autenticazione per i commenti della richiesta pull per i contributi

Questa versione aggiunge un nuovo ambito OAuth per la lettura/scrittura di commenti delle richieste pull. Se si ha un bot o un'automazione che deve interagire solo con i commenti, è possibile assegnargli un token di accesso personale solo con questo ambito. Questo processo riduce il raggio dell'esplosione se l'automazione presenta un bug o se il token è stato compromesso.

Miglioramenti dell'esperienza di richiesta pull

La nuova esperienza di richiesta pull è stata migliorata con quanto segue:

  • Rendere i controlli facoltativi più visibili

I clienti usano controlli facoltativi per attirare l'attenzione di uno sviluppatore su potenziali problemi. Nell'esperienza precedente, è stato usato per essere ovvio quando questi controlli hanno esito negativo. Tuttavia, questo non è il caso nell'esperienza di anteprima. Un segno di spunta grande e verde sui controlli necessari maschera gli errori nei controlli facoltativi. Gli utenti potrebbero rilevare che i controlli facoltativi non sono riusciti aprendo il pannello dei controlli. Gli sviluppatori spesso non lo fanno quando non c'è alcuna indicazione di un problema. In questa distribuzione è stato reso più visibile lo stato dei controlli facoltativi nel riepilogo.


visualizzare i controlli facoltativi


  • Ctrl-clic sulle voci di menu

I menu di tabulazioni in una richiesta pull non supportano ctrl-clic. Gli utenti spesso aprono nuove schede del browser durante la revisione di una richiesta pull. Questo problema è stato risolto.

  • Posizione dell'annotazione [+]

L'elenco ad albero dei file in una richiesta pull mostra un'annotazione [+] per aiutare gli autori e i revisori a identificare i nuovi file. Poiché l'annotazione era dopo i puntini di sospensione, spesso non era visibile per nomi di file più lunghi.


mostra le posizioni delle annotazioni

  • Elenco a discesa aggiornamenti della richiesta pull per recuperare le informazioni di temporizzazione

L'elenco a discesa per selezionare l'aggiornamento e confrontare i file in una richiesta pull ha perso un elemento importante nell'esperienza di anteprima. Non è stato visualizzato quando è stato eseguito l'aggiornamento. Questo problema è stato risolto.


Informazioni sulla tempistica mancante per gli aggiornamenti delle richieste pull

  • **Layout del filtro dei commenti migliorato **

Quando si filtrano i commenti nella pagina di riepilogo di una richiesta pull, l'elenco a discesa si trovava a destra, ma il testo era allineato a sinistra. Questo problema è stato risolto.


Layout del filtro dei commenti migliorato

  • Navigazione ai commit padre

Nella pagina Commit è possibile confrontare le modifiche apportate in un determinato commit con il commit padre. Tuttavia, è possibile passare al commit padre e comprendere in modo più approfondito il modo in cui il commit differisce dal proprio padre. Questa operazione è spesso necessaria quando si vogliono comprendere tutte le modifiche apportate a una versione. È stata aggiunta una scheda padre a un commit per ottenere questo risultato.


Navigazione ai commit padre

  • Più spazio per cartelle e file con nomi lunghi nella scheda File pull

Cartelle e file con nomi lunghi sono stati tagliati a causa di una mancanza di spaziatura orizzontale nell'albero dei file. È stato recuperato spazio aggiuntivo nell'albero modificando il rientro dell'albero in modo che corrisponda al nodo radice e nascondendo il pulsante con i puntini di sospensione dalla pagina, ad eccezione del passaggio del mouse.

Immagine della nuova struttura ad albero dei file:


Più spazio per cartelle e file

Immagine dell'albero dei file quando si passa il puntatore del mouse su una directory:


Visualizzazione nome

  • Mantieni la posizione di scorrimento durante il ridimensionamento del riquadro delle differenze nella scheda File pull

Quando si ridimensiona il riquadro delle differenze side-by-side nella scheda File pull, la posizione di scorrimento dell'utente andrebbe persa. Questo problema è stato risolto; la posizione di scorrimento dell'utente viene ora mantenuta in un ridimensionamento del riquadro delle differenze.

  • Cercare un commit in un dispositivo mobile

Quando si visualizza la pagina Commit in un dispositivo mobile, la casella di ricerca non è presente nella nuova esperienza. Di conseguenza, è difficile trovare un commit in base al relativo hash e aprirlo. Questo problema è stato risolto.


Cercare un commit in un dispositivo mobile

  • Miglioramento dell'utilizzo dello spazio per la visualizzazione mobile delle differenze dei file di richiesta pull

Questa pagina è stata aggiornata per usare meglio lo spazio in modo che gli utenti possano visualizzare più file nelle visualizzazioni per dispositivi mobili invece di avere il 40% dello schermo occupato da un'intestazione.


Miglioramento dell'utilizzo dello spazio nuovo nome file della richiesta pull

  • Immagini avanzate nella visualizzazione riepilogo delle richieste pull

Le immagini modificate in una richiesta pull non venivano visualizzate nella visualizzazione di riepilogo della richiesta pull, ma venivano visualizzate correttamente nella visualizzazione dei file di richiesta pull. Questo problema è stato risolto.

  • Esperienza avanzata dei rami durante la creazione di una nuova richiesta pull

Prima di questo aggiornamento, questa esperienza non era ideale perché confrontava le modifiche con il ramo predefinito del repository anziché con il ramo di confronto.


Miglioramento dell'esperienza del ramo

Pipelines

Piattaforma agente aggiuntiva: ARM64

È stato aggiunto Linux/ARM64 all'elenco delle piattaforme supportate per l'agente di Azure Pipelines. Anche se le modifiche al codice sono state minime, è stato necessario prima completare molte operazioni dietro le quinte e siamo lieti di annunciarne il rilascio.

Supporto del filtro tag per le risorse della pipeline

Sono stati aggiunti "tag" nelle pipeline YAML. È possibile usare i tag per impostare la pipeline di integrazione continua da eseguire o quando attivare automaticamente.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: master
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

Il frammento di codice precedente mostra che i tag possono essere usati per determinare la versione predefinita della pipeline ci (integrazione continua) da eseguire quando l'esecuzione della pipeline cd (distribuzione continua) non viene attivata da un'altra origine/risorsa o da un trigger di esecuzione pianificato.

Ad esempio, se è stato impostato un trigger pianificato per la pipeline CD che si vuole eseguire solo se l'integrazione continua ha il tag di produzione, i tag nella sezione trigger assicurano che la pipeline CD venga attivata solo se la condizione di assegnazione di tag viene soddisfatta dall'evento di completamento CI.

Controllare quali attività sono consentite nelle pipeline

È ora possibile disabilitare le attività del Marketplace. Alcuni utenti possono consentire estensioni del Marketplace, ma non le attività pipeline che portano avanti. Per un maggiore controllo, è anche possibile disabilitare in modo indipendente tutte le attività incluse nella casella (ad eccezione del checkout, che è un'azione speciale). Con entrambe queste impostazioni abilitate, le uniche attività consentite per l'esecuzione in una pipeline sono quelle caricate usando tfx. Per iniziare, visitare https://dev.azure.com/<your_org>/_settings/pipelinessettings e cercare la sezione denominata "Restrizioni delle attività".

Criteri di blocco della distribuzione esclusivi

Con questo aggiornamento, è possibile assicurarsi che solo una singola esecuzione venga distribuita in un ambiente alla volta. Scegliendo il controllo "Blocco esclusivo" in un ambiente, verrà eseguita una sola esecuzione. Le esecuzioni successive che vogliono eseguire la distribuzione in tale ambiente verranno sospese. Al termine dell'esecuzione con il blocco esclusivo, l'esecuzione più recente procederà. Tutte le esecuzioni intermedie verranno annullate.

Nella pagina Aggiungi controllo selezionare Blocco esclusivo per assicurarsi che solo una singola esecuzione venga distribuita in un ambiente alla volta.

Filtri di fasi per i trigger delle risorse della pipeline

È stato aggiunto il supporto per le "fasi" come filtro per le risorse della pipeline in YAML. Con questo filtro non è necessario attendere il completamento dell'intera pipeline ci per attivare la pipeline CD. È ora possibile scegliere di attivare la pipeline cd al completamento di una fase specifica nella pipeline ci.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

Quando le fasi fornite nel filtro trigger vengono completate correttamente nella pipeline ci, viene attivata automaticamente una nuova esecuzione per la pipeline CD.

Trigger basati su webhook generici per le pipeline YAML

Attualmente sono disponibili varie risorse, ad esempio pipeline, contenitori, compilazione e pacchetti, tramite cui è possibile usare gli artefatti e abilitare trigger automatizzati. Fino ad ora, tuttavia, non è possibile automatizzare il processo di distribuzione in base ad altri eventi o servizi esterni. In questa versione viene introdotto il supporto del trigger webhook nelle pipeline YAML per abilitare l'integrazione dell'automazione della pipeline con qualsiasi servizio esterno. È possibile sottoscrivere qualsiasi evento esterno tramite i relativi webhook (Github, Github Enterprise, Nexus, Aritfactory e così via) e attivare le pipeline.

Ecco i passaggi per configurare i trigger webhook:

  1. Configurare un webhook nel servizio esterno. Quando si crea il webhook, è necessario fornire le informazioni seguenti:

    • URL richiesta: "https://dev.azure.com/<raccolta> ADO/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"
    • Segreto: opzione facoltativa. Se è necessario proteggere il payload JSON, specificare il valore Secret

  2. Creare una nuova connessione al servizio "Webhook in ingresso". Si tratta di un nuovo tipo di connessione al servizio introdotto che consentirà di definire tre importanti informazioni:

    • Nome webhook: il nome del webhook deve corrispondere al webhook creato nel servizio esterno.
    • Intestazione HTTP : nome dell'intestazione HTTP nella richiesta che contiene il valore hash del payload per la verifica della richiesta. Ad esempio, nel caso di GitHub, l'intestazione della richiesta sarà "X-Hub-Signature"
    • Segreto : il segreto viene usato per analizzare l'hash del payload usato per la verifica della richiesta in ingresso (questo è facoltativo). Se è stato usato un segreto per la creazione del webhook, sarà necessario fornire la stessa chiave privata

    Nella pagina Modifica connessione al servizio configurare i trigger webhook.

  3. Viene introdotto un nuovo tipo di risorsa chiamato webhooks nelle pipeline YAML. Per sottoscrivere un evento webhook, è necessario definire una risorsa webhook nella pipeline e puntare alla connessione al servizio webhook in ingresso. È anche possibile definire filtri aggiuntivi sulla risorsa webhook in base ai dati del payload JSON per personalizzare ulteriormente i trigger per ogni pipeline ed è possibile usare i dati del payload sotto forma di variabili nei processi.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}
  1. Ogni volta che viene ricevuto un evento webhook dalla connessione al servizio Webhook in ingresso, verrà attivata una nuova esecuzione per tutte le pipeline sottoscritte all'evento webhook.

Problemi di attivazione delle risorse YAML supportano e tracciabilità

Può generare confusione quando i trigger della pipeline non riescono a essere eseguiti come previsto. Per comprendere meglio questo problema, è stata aggiunta una nuova voce di menu nella pagina di definizione della pipeline denominata "Problemi di trigger" in cui vengono visualizzate informazioni sul motivo per cui i trigger non sono in esecuzione.

I trigger di risorsa possono non essere eseguiti per due motivi.

  1. Se l'origine della connessione al servizio specificata non è valida o se sono presenti errori di sintassi nel trigger, il trigger non verrà configurato affatto. Questi vengono visualizzati come errori.

  2. Se le condizioni del trigger non corrispondono, il trigger non verrà eseguito. Ogni volta che si verifica questo problema, viene visualizzato un avviso in modo da poter comprendere il motivo per cui le condizioni non sono state soddisfatte.

    Questa pagina di definizione della pipeline denominata Problemi di trigger visualizza informazioni sul motivo per cui i trigger non sono in esecuzione.

Trigger multi-repository

È possibile specificare più repository in un file YAML e causare l'attivazione di una pipeline tramite aggiornamenti a uno qualsiasi dei repository. Questa funzionalità è utile, ad esempio, negli scenari seguenti:

  • Si utilizza uno strumento o una libreria da un repository diverso. Si vogliono eseguire test per l'applicazione ogni volta che viene aggiornato lo strumento o la libreria.
  • Il file YAML viene mantenuto in un repository separato dal codice dell'applicazione. Si vuole attivare la pipeline ogni volta che viene eseguito il push di un aggiornamento nel repository dell'applicazione.

Con questo aggiornamento, i trigger di più repository funzioneranno solo per i repository Git in Azure Repos. Non funzionano per le risorse del repository GitHub o BitBucket.

Di seguito è riportato un esempio che illustra come definire più risorse del repository in una pipeline e come configurare i trigger in tutti.

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

La pipeline in questo esempio verrà attivata se sono presenti aggiornamenti per:

  • main ramo nel self repository contenente il file YAML
  • main o release rami nel tools repository

Per altre informazioni, vedere Più repository nella pipeline.

Caricamenti dei log dell'agente migliorati

Quando un agente smette di comunicare con il server Azure Pipelines, il processo in esecuzione viene abbandonato. Se è successo di guardare i log della console di streaming, potrebbe essere stato ottenuto alcuni indizi su ciò che l'agente era fino a destra prima di interrompere la risposta. Ma se non si era o se è stata aggiornata la pagina, i log della console sono andati. Con questa versione, se l'agente smette di rispondere prima di inviare i log completi, manterrà i log della console come cosa migliore. I log della console sono limitati a 1000 caratteri per riga e possono essere occasionalmente incompleti, ma sono molto più utili di non mostrare nulla! L'esame di questi log può aiutare a risolvere i problemi delle proprie pipeline e sarà certamente utile ai tecnici di supporto quando aiutano a risolvere i problemi.

Facoltativamente montare i volumi dei contenitori di sola lettura

Quando si esegue un processo contenitore in Azure Pipelines, diversi volumi contenenti l'area di lavoro, le attività e altri materiali vengono mappati come volumi. Questi volumi sono predefiniti per l'accesso in lettura/scrittura. Per aumentare la sicurezza, è possibile montare i volumi di sola lettura modificando la specifica del contenitore in YAML. Ogni chiave in mountReadOnly può essere impostata su true per la sola lettura (il valore predefinito è false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

Controllo con granularità fine sull'avvio/arresto del contenitore

In generale, è consigliabile consentire ad Azure Pipelines di gestire il ciclo di vita dei contenitori di processi e servizi. Tuttavia, in alcuni scenari non comuni, è possibile iniziare e arrestarli autonomamente. Con questa versione è stata compilata questa funzionalità nell'attività Docker.

Ecco una pipeline di esempio usando la nuova funzionalità:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

Inoltre, è incluso l'elenco di contenitori in una variabile della pipeline, Agent.ContainerMapping. È possibile usare questa opzione se si vuole controllare l'elenco di contenitori in uno script, ad esempio. Contiene un oggetto JSON stringato che esegue il mapping del nome della risorsa ("builder" dall'esempio precedente) all'ID contenitore gestito dall'agente.

Decomprimere i bundle di attività per ogni passaggio

Quando l'agente esegue un processo, scarica innanzitutto tutti i bundle di attività richiesti dai passaggi del processo. Normalmente, per le prestazioni, decomprime le attività una volta per processo anche se l'attività viene usata in più passaggi. Se si hanno problemi relativi al codice non attendibile che modifica il contenuto non attendibile, è possibile scambiare un po'di prestazioni con l'agente decomprimere l'attività in ogni utilizzo. Per abilitare questa modalità, passare --alwaysextracttask quando si configura l'agente.

Migliorare la sicurezza delle versioni limitando l'ambito dei token di accesso

In base all'iniziativa per migliorare le impostazioni di sicurezza per Azure Pipelines, è ora possibile limitare l'ambito dei token di accesso per le versioni.

Ogni processo eseguito nelle versioni ottiene un token di accesso. Il token di accesso viene usato dalle attività e dagli script per eseguire nuovamente la chiamata ad Azure DevOps. Ad esempio, viene usato il token di accesso per ottenere codice sorgente, scaricare elementi, caricare log, risultati di test o eseguire chiamate REST in Azure DevOps. Un nuovo token di accesso viene generato per ogni processo e scade al termine del processo.

Con questo aggiornamento, è possibile migliorare la sicurezza della pipeline limitando l'ambito dei token di accesso e estendendo lo stesso alle versioni classiche.

Questa funzionalità verrà attivata per impostazione predefinita per nuovi progetti e raccolte. Per le raccolte esistenti, è necessario abilitarla in Impostazioni > pipeline di > raccolta. > Limitare l'ambito dell'autorizzazione del processo al progetto corrente per le pipeline di rilascio. Fare clic qui per altre informazioni.

Miglioramenti dell'API di anteprima YAML

È ora possibile visualizzare in anteprima il file YAML completo di una pipeline senza eseguirlo. È stato inoltre creato un nuovo URL dedicato per la funzionalità di anteprima. A questo punto è possibile eseguire il post per https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview recuperare il corpo YAML finalizzato. Questa nuova API accetta gli stessi parametri dell'accodamento di un'esecuzione, ma non richiede più l'autorizzazione "Build code".

Eseguire il processo successivo

Si è mai avuto un bugfix che è necessario distribuire in questo minuto , ma è stato necessario attendere i processi CI e PR? Con questa versione è ora possibile aumentare la priorità di un processo in coda. Gli utenti con l'autorizzazione "Gestisci" per il pool, in genere gli amministratori del pool, visualizzeranno un nuovo pulsante "Esegui successivo" nella pagina dei dettagli del processo. Facendo clic sul pulsante verrà impostato il processo da eseguire il prima possibile. (È ancora necessario parallelismo disponibile e un agente adatto, naturalmente).

Espressioni di modello consentite nel blocco YAML resources

In precedenza, le espressioni di compilazione (${{ }}) non sono state consentite nella resources sezione di un file YAML di Azure Pipelines. Con questa versione è stata revocata questa restrizione per i contenitori. In questo modo è possibile usare il contenuto del parametro di runtime all'interno delle risorse, ad esempio per selezionare un contenitore in fase di coda. Si prevede di estendere questo supporto ad altre risorse nel tempo.

Controllare gli aggiornamenti automatici delle attività dal Marketplace

Quando si scrive una pipeline YAML, in genere si specifica solo il numero di versione principale delle attività incluse. Ciò consente alle pipeline di eseguire automaticamente le aggiunte e le correzioni di bug più recenti. A volte potrebbe essere necessario eseguire il rollback a una versione precedente di un'attività e con questo aggiornamento è stata aggiunta la possibilità di eseguire questa operazione. È ora possibile specificare una versione completa dell'attività major.minor.patch nelle pipeline YAML.

Non è consigliabile eseguire questa operazione regolarmente e usarla solo come soluzione alternativa temporanea quando si rileva che una nuova attività interrompe le pipeline. Inoltre, non verrà installata una versione precedente di un'attività dal Marketplace. Deve già esistere nella raccolta o la pipeline avrà esito negativo.

Esempio:

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

Supporto del nodo 10 nell'agente e nelle attività

Poiché il nodo 6 non è più supportato, viene eseguita la migrazione delle attività in modo che funzioni con Node 10. Per questo aggiornamento, è stata eseguita la migrazione quasi del 50% delle attività in-box a Node 10. L'agente può ora eseguire sia le attività Node 6 che Node 10. In un aggiornamento futuro verrà rimosso completamente il nodo 6 dall'agente. Per preparare la rimozione del nodo 6 dall'agente, è necessario aggiornare le estensioni interne e le attività personalizzate per usare presto node 10. Per usare Node 10 per l'attività, in , in task.json, executionaggiornare da Node a Node10.

Migliorare la conversione YAML nella finestra di progettazione di compilazione classica

Con questa versione viene introdotta una nuova funzionalità "esporta in YAML" per le pipeline di compilazione della finestra di progettazione. Salvare la definizione della pipeline, quindi trovare "Esporta in YAML" nel ... menu.

La nuova funzione di esportazione sostituisce la funzione "View as YAML" precedentemente trovata nella finestra di progettazione della compilazione classica. Questa funzione era incompleta perché poteva solo controllare ciò che l'interfaccia utente Web sapeva sulla compilazione, che a volte ha portato a generare YAML non corretto. La nuova funzione di esportazione tiene conto esattamente della modalità di elaborazione della pipeline e genera YAML con fedeltà completa alla pipeline di progettazione.

Nuova conversione della piattaforma Web : impostazioni del repository

Sono state convertite le due pagine delle impostazioni del repository in un'unica esperienza aggiornata a una nuova piattaforma Web. Questo aggiornamento non solo rende l'esperienza più veloce e più moderna, ma queste pagine forniscono anche un singolo punto di ingresso per tutti i criteri dal livello di progetto al livello di ramo.

Nuova conversione della piattaforma Web.

Con questa nuova esperienza, lo spostamento per i progetti con un numero notevole di repository è diventato più semplice a causa di tempi di caricamento più rapidi e di un filtro di ricerca aggiunto. È anche possibile visualizzare i criteri a livello di progetto e l'elenco dei criteri tra repository nella scheda Criteri.

Visualizzare i criteri tra repository nella scheda Criteri.

Se si fa clic su un repository, è possibile visualizzare i criteri e le autorizzazioni impostati a livello di repository. Nella scheda criteri è possibile visualizzare un elenco di ogni ramo impostato su. Fare quindi clic sul ramo per visualizzare tutti i criteri senza lasciare la pagina Impostazioni repository.

Selezionare Branch per visualizzare i criteri.

Ora, quando i criteri vengono ereditati da un ambito superiore a quello con cui si lavora, viene illustrato dove i criteri sono stati ereditati da accanto a ogni singolo criterio. È anche possibile passare alla pagina in cui è stato impostato il criterio di livello superiore facendo clic sul nome dell'ambito.

Mostra da dove è stato ereditato il criterio.

La pagina dei criteri stessa è stata aggiornata anche alla nuova piattaforma Web con sezioni collapsible! Per migliorare l'esperienza di ricerca di un determinato criterio di convalida della compilazione, controllo stato o revisore automatico, sono stati aggiunti filtri di ricerca per ogni sezione.

Cercare filtri per ogni sezione.

Integrazione della gestione delle modifiche di ServiceNow con pipeline YAML

L'app Azure Pipelines per ServiceNow consente di integrare Azure Pipelines e ServiceNow Change Management. Con questo aggiornamento, viene effettuato il percorso per rendere Azure Pipelines consapevole del processo di gestione delle modifiche gestito in ServiceNow oltre alle pipeline YAML.

Configurando il controllo "ServiceNow Change Management" in una risorsa, è ora possibile sospendere la modifica da approvare prima di distribuire la compilazione in tale risorsa. È possibile creare automaticamente una nuova modifica per una fase o attendere una richiesta di modifica esistente.


Integrazione della gestione delle modifiche di ServiceNow

È anche possibile aggiungere l'attività in un processo server per aggiornare la UpdateServiceNowChangeRequest richiesta di modifica con stato di distribuzione, note e così via.

Artifacts

Possibilità di creare feed con ambito organizzazione dall'interfaccia utente

I clienti possono creare e gestire feed con ambito raccolta tramite l'interfaccia utente Web sia per i servizi prem che per i servizi ospitati.

È ora possibile creare feed con ambito organizzazione tramite l'interfaccia utente, passando ad Artefatti -> Crea feed e scegliendo un tipo di feed all'interno di Ambito.

Creare feed con ambito raccolta selezionando Artefatti, quindi Crea feed e selezionando un tipo di feed all'interno di Ambito.

Anche se è consigliabile usare feed con ambito progetto in allineamento con il resto delle offerte di Azure DevOps, è possibile creare, gestire e usare feed con ambito raccolta tramite l'interfaccia utente e varie API REST. Per altre informazioni, vedere la documentazione dei feed.

Aggiornare l'API REST della versione del pacchetto ora disponibile per i pacchetti Maven

È ora possibile usare l'API REST "Aggiorna versione pacchetto" di Azure Artifacts per aggiornare le versioni dei pacchetti Maven. In precedenza, è possibile usare l'API REST per aggiornare le versioni dei pacchetti per NuGet, Maven, npm e Universal Packages, ma non per i pacchetti Maven.

Per aggiornare i pacchetti Maven, usare il comando HTTP PATCH come indicato di seguito.

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

È possibile impostare quanto segue:

Parametri dell'URI

Nome In Obbligatorio Tipo Descrizione
artifactId path true string ID artefatto del pacchetto
feed path true string Nome o ID del feed
groupId path true string ID gruppo del pacchetto
collection path true string Nome della raccolta di Azure DevOps
version path true string Versione del pacchetto
project path string ID progetto o nome del progetto
api-version query true string Versione dell'API da usare. Deve essere impostato su '5.1-preview.1' per usare questa versione dell'API

Corpo della richiesta

Nome Tipo Descrizione
Viste JsonPatchOperation Visualizzazione a cui verrà aggiunta la versione del pacchetto

Per altre informazioni, vedere la documentazione dell'API REST quando viene aggiornata.

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