Condividi tramite

Note sulla versione di Azure DevOpsServer 2020 Update 1

  • Articolo

Requisiti di sistema della | community | degli sviluppatori Condizioni | di licenza DevOps Blog | HASH SHA-1

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, visitare la pagina download di Azure DevOps Server.

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

Eseguire l'aggiornamento sicuro da Azure DevOps Server 2019 ad Azure DevOps Server 2020

Azure DevOps Server 2020 introduce un nuovo modello di conservazione di esecuzione della pipeline (compilazione) basato sulle impostazioni a livello di progetto.

Azure DevOps Server 2020 gestisce la conservazione della compilazione in modo diverso, 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.

Leggere il post di blog per altre informazioni su come eseguire l'aggiornamento sicuro da Azure DevOps Server 2019 ad Azure DevOps Server 2020.

Data di rilascio di Azure DevOps Server 2020 Update 1.2 Patch 13: 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 per cui il server proxy smetteva di funzionare dopo l'installazione di Patch 12.

Data di rilascio di Azure DevOps Server 2020 Update 1.2 Patch 12: 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 per cui lo spazio su disco usato dalla cartella della cache proxy è stato calcolato in modo non corretto e la cartella non è stata pulita correttamente.
  • CVE-2024-20667: vulnerabilità di esecuzione remota del codice di Azure DevOps Server.

Data di rilascio di Azure DevOps Server 2020 Update 1.2 Patch 11: 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 per cui l'ereditarietà della sicurezza dell'approvazione preliminare della distribuzione non funzionava nelle fasi delle pipeline.

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

È stata rilasciata una patch per Azure DevOps Server 2020 Update 1.2 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.

Nota

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

Installare le 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 della patch 8 sarà 3.225.0.

Configurare TFX

  1. Seguire la procedura descritta nella documentazione relativa al caricamento delle attività nella raccolta di progetti per installare e accedere con tfx-cli.

Aggiornare le attività con TFX

file Hash SHA-256
Tasks20231103.zip 389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9F9EFCED5034D2E5
  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, è necessario impostare una variabile AZP_75787_ENABLE_NEW_LOGIC = true nelle pipeline che usano le attività interessate.

  • In versione classica:

    Definire la variabile nella scheda della variabile nella pipeline.

  • Esempio YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true

Data di rilascio di Azure DevOps Server 2020 Update 1.2 Patch 9: 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 della patch 8 sarà 3.225.0.

Abbiamo rilasciato una patch. per Azure DevOps Server 2020 Update 1.2 che include correzioni per quanto segue.

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

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

È stata rilasciata una patch per Azure DevOps Server 2020 Update 1.2 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.

Importante

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

Nota

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

Installare le 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 il downgrade dell'agente. In Windows è possibile usare il comando seguente in un prompt dei comandi amministrativo, seguito da un riavvio. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Configurare TFX

  1. Seguire la procedura descritta nella documentazione relativa al caricamento delle attività nella 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, è necessario impostare una variabile AZP_75787_ENABLE_NEW_LOGIC = true nelle pipeline che usano le attività interessate.

  • In versione classica:

    Definire la variabile nella scheda della variabile nella pipeline.

  • Esempio YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true

Data di rilascio di Azure DevOps Server 2020 Update 1.2 Patch 7: 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à spoofing del server Azure DevOps.
  • Aggiornare il servizio SSH per supportare SHA2-256 e SHA2-512. Se sono hardcoded file di configurazione SSH per usare RSA, è necessario 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 lo 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.

Data di rilascio di Azure DevOps Server 2020 Update 1.2 Patch 6: 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à spoofing del server Azure DevOps.
  • CVE-2023-21569: vulnerabilità spoofing del server Azure DevOps.
  • Correzione di un bug che interferisce con il push dei pacchetti durante l'aggiornamento dalla versione 2018 o precedente.
  • 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 2020 Update 1.2 Patch 5: 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 di codice remoto di Azure DevOps Server
  • Correzione del problema di accessibilità degli scaffali tramite l'interfaccia utente Web
  • I clienti devono riavviare il servizio tfsjobagent e il pool di applicazioni di Azure DevOps Server dopo aver aggiornato l'impostazione correlata a SMTP in Azure DevOps Server Management Console.

Data di rilascio di Azure DevOps Server 2020 Update 1.2 Patch 4: 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 di caratteri 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.

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

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

  • Risolvere il problema con le identità di Active Directory appena aggiunte che non vengono visualizzate nei selettore identità della finestra di dialogo di sicurezza.
  • Consente di risolvere un problema relativo al filtro Membro del gruppo nelle impostazioni di web hook.
  • Correzione dell'errore di compilazione check-in gated quando le impostazioni dell'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 la connessione al servizio dietro il proxy autenticato.

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

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

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

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

Data di rilascio dell'aggiornamento 1.2 di Azure DevOps Server 2020: 17 maggio 2022

Azure DevOps Server 2020 Update 1.2 è un rollup delle 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 3 build 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 Minimo per mantenere

  • I collegamenti dei commenti degli scaffali e del set di modifiche 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 personali dopo che l'account Active Directory di un utente è disabilitato.

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

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

  • Le notifiche tramite posta elettronica 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.

Passaggi di installazione

  1. Aggiornare il server con 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. Potrebbe essere restituito un avviso simile al seguente: Impossibile connettersi al server remoto. Non chiudere la finestra, perché l'aggiornamento esegue nuovi tentativi finché non viene completato.

Nota

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

  1. Aggiornare il server con 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 C:\Program Files\{TFS Version Folder}\Search\zip nella cartella del file remoto elasticsearch.
  4. Eseguire Configure-TFSSearch.ps1 -Operation update nel computer del server Elasticsearch.

Hash SHA-256: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Data di rilascio di Azure DevOps Server 2020.1.1 Patch 3: 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 contengono 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.

Data di rilascio di Azure DevOps Server 2020.1.1 Patch 2: 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 i 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 di 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.
  • Correzione del problema relativo all'invio di messaggi di posta elettronica per confermare l'aggiornamento del prodotto.

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

Data di rilascio dell'aggiornamento 1.1 di Azure DevOps Server 2020: 17 agosto 2021

Azure DevOps Server 2020 Update 1.1 è un rollup delle correzioni di bug. È possibile installare direttamente Azure DevOps Server 2020 Update 1.1 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.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

  • Sono state corrette caselle di controllo di ereditarietà dei tipi di merge limitate per abilitare la modifica dei tipi di unione dopo l'impostazione dei criteri di cross-reposity.

Azure Pipelines

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

Generali

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

Azure Test Plans

  • Non è possibile tornare ai risultati dei test dopo aver eseguito il ripristino dalla cronologia alla pagina di riepilogo.

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

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

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

Data di rilascio di 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 con Notifications SDK. In precedenza, le sottoscrizioni delle notifiche che usano il filtro Percorso area non venivano analizzate correttamente.

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

Riepilogo delle novità di Azure DevOps Server 2020.1 RTW

Azure DevOps Server 2020.1 RTW è un rollup di correzioni di bug. Include tutte le funzionalità di Azure DevOps Server 2020.1 RC2 rilasciate in precedenza. Azure DevOps Server 2020.1 RTW è un rollup di correzioni di bug. È possibile installare direttamente Azure DevOps Server 2020.1 o eseguire 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.

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

Riepilogo delle novità di Azure DevOps Server 2020.1 RC2

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

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

Riepilogo delle novità di 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 per la transizione di stato

Continuiamo a chiudere il divario tra xml ospitato e il modello di processo ereditato. Questa nuova regola del tipo di elemento di lavoro consente di limitare lo spostamento degli elementi di lavoro da uno stato a un altro. Ad esempio, è possibile limitare i bug dal passaggio 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 "Responsabili approvazione" possono spostare le storie utente da Nuovo -> Approvato.

Copiare l'elemento di lavoro per copiare elementi figlio

Una delle principali funzionalità 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 per 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 Activated By, Activated Date, Resolved By e Resolved Date sono state un mistero. Sono impostati solo per i tipi di elementi 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. Si supponga, ad esempio, di avere uno stato personalizzato "Needs Testing" nella categoria Risolta. Quando l'elemento di lavoro passa da "Active" a "Needs Testing", vengono attivate le regole Resolved By e Resolved Date .

In questo modo i clienti possono creare valori di stato personalizzati e generare comunque i campi Activated By, Activated Date, Resolved By e Resolved Date, senza la necessità di usare regole personalizzate.

Gli stakeholder possono spostare gli elementi di lavoro tra le colonne della lavagna

Gli stakeholder sono sempre stati in grado di modificare lo stato degli elementi di lavoro. Ma quando passano alla lavagna Kanban, non riescono a 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 lieti di annunciare che ora è possibile spostare gli elementi di lavoro tra le colonne della lavagna.

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

È ora possibile aggiungere un tipo di elemento di lavoro di sistema al livello di backlog preferito. 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
Revisione
Rischio

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

Backlog

Limite di repository dell'app GitHub di Azure Boards elevato

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 eseguito il merge della 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, analizziamo la descrizione della richiesta pull e cerchiamo il valore dello stato seguito dal #mention degli elementi di lavoro. In questo esempio si impostano due storie utente su Risolto e si chiudeno due attività.

stato dell'elemento di lavoro

È ora possibile tenere traccia facilmente delle dipendenze di compilazione nel progetto collegando l'elemento di lavoro a una compilazione, disponibile in compilazione o integrata 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 l'ereditarietà che impediva ad alcuni clienti di eseguire la migrazione al modello ereditato. È ora possibile modificare la descrizione nei campi di sistema. Il valore modificato influirà 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 diversi tipi di elementi di lavoro.

modifica descrizione

Personalizzare lo stato dell'elemento di lavoro quando viene eseguito il merge della 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 questo scopo, è ora possibile usare commenti come quelli illustrati nella figura seguente. Per altri dettagli, vedere la documentazione.

Personalizzare lo stato

Campo padre nella bacheca delle attività

A causa di una 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 per oltre un decennio e hanno generalmente 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 era il momento di rimuoverlo. Questa regola esiste nel tipo di elemento di lavoro Bug nel processo Agile.

"Impostare il valore Assegnato su Created By quando lo stato viene modificato in Resolved"

Abbiamo ricevuto un sacco di 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 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 di nuovo per aggiungere nuovamente la regola usando regole personalizzate.

Rimozione di elementi 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 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 predefinito

Azure Repos offre ora 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 predefinito del ramo per un repository esistente.

Per altre informazioni, vedere Gestire i rami e Modificare il ramo predefinito.

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 valore predefinito definito da Azure DevOps.

Impostazione del ramo per il livello dell'organizzazione

Aggiungere un nuovo ambito di autenticazione per contribuire con commenti alla richiesta pull

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 pat solo con questo ambito. Questo processo riduce il raggio dell'esplosione se l'automazione presenta un bug o se il token è stato compromesso.

Miglioramenti all'esperienza richiesta pull

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

  • Rendere più visibili i controlli facoltativi

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 verde grande sui controlli necessari maschera gli errori nei controlli facoltativi. Gli utenti potrebbero scoprire 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 a schede di 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 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

  • L'elenco a discesa aggiornamenti della richiesta pull ripristina le informazioni sulla tempistica

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.


L'elenco a discesa aggiornamenti della richiesta pull non contiene informazioni sulla tempistica

  • **Layout del filtro dei commenti migliorato **

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


Layout del filtro dei commenti migliorato

  • Passaggio 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 relativo padre. Questo è spesso necessario quando si desidera comprendere tutte le modifiche in una versione. È stata aggiunta una scheda padre a un commit per ottenere questo risultato.


Passaggio ai commit padre

  • Più spazio per cartelle e file con nomi lunghi nella scheda dei file delle richieste 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:


Maggiore spazio per cartelle e file

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


Visualizzazione nome

  • Conservazione della posizione di scorrimento durante il ridimensionamento del riquadro differenziale nella scheda di file delle richieste pull

Quando si ridimensiona il riquadro diff 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 diff.

  • Ricerca di 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 ora.


Ricerca di un commit in un dispositivo mobile

  • Miglioramento dell'utilizzo dello spazio per la nuova visualizzazione differenziale per dispositivi mobili per i file delle richieste 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 di richiesta pull

  • Immagini avanzate nella visualizzazione di riepilogo delle richieste pull

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

  • Miglioramento dell'esperienza 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é il ramo di confronto.


Miglioramento dell'esperienza dei rami

Pipeline

Piattaforma agente aggiuntiva: ARM64

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

Supporto del filtro di tag per le risorse della pipeline

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

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    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.

Controllo delle attività 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 da distribuire 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 di 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 di integrazione continua per attivare la pipeline cd. È ora possibile scegliere di attivare la pipeline cd al completamento di una fase specifica nella pipeline di integrazione continua.

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 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: facoltativo. Se è necessario proteggere il payload JSON, specificare il valore Secret

  2. Creare una nuova connessione al servizio "Webhook in ingresso". Si tratta di un tipo di connessione al servizio appena 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 contenente 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 specificare la stessa chiave privata

    Nella pagina Modifica connessione al servizio configurare i trigger webhook.

  3. Un nuovo tipo di risorsa chiamato webhooks viene introdotto 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 un evento webhook viene ricevuto 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: supporto 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 relative al 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 errori 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 comprendere il motivo per cui le condizioni non sono state soddisfatte.

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

Trigger multi-repository

È possibile specificare più repository in un file YAML e fare in modo che una pipeline si attivi da 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 multi-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 su 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.

Miglioramento dei caricamenti dei log dell'agente

Quando un agente smette di comunicare con il server Azure Pipelines, il processo in esecuzione diventa abbandonato. Se è capitato di esaminare i log della console di streaming, si potrebbero aver ottenuto alcuni indizi su ciò che l'agente era fino a destra prima che smettesse di rispondere. Tuttavia, se non lo fosse o se è stata aggiornata la pagina, i log della console non sono più disponibili. Con questa versione, se l'agente smette di rispondere prima che invii i log completi, i log della console verranno mantenuto come la cosa migliore. I log della console sono limitati a 1000 caratteri per riga e possono occasionalmente essere incompleti, ma sono molto più utili che non mostrare nulla. L'analisi di questi log può aiutare a risolvere i problemi delle proprie pipeline e sarà certamente utile ai tecnici del supporto tecnico per facilitare la risoluzione dei problemi.

Montaggio facoltativo di volumi di contenitori di sola lettura

Quando si esegue un processo contenitore in Azure Pipelines, vengono mappati diversi volumi contenenti l'area di lavoro, le attività e altri materiali. Per impostazione predefinita, questi volumi hanno accesso in lettura/scrittura. Per una maggiore 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 a granularità fine sull'avvio/arresto dei contenitori

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, è consigliabile avviarli e arrestarli manualmente. Con questa versione, questa funzionalità è stata compilata nell'attività Docker.

Ecco una pipeline di esempio che usa 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

Si include anche l'elenco dei contenitori in una variabile della pipeline, Agent.ContainerMapping. È possibile usarlo se si vuole esaminare l'elenco di contenitori in uno script, ad esempio. Contiene un oggetto JSON stringato che esegue il mapping del nome della risorsa ("builder" dell'esempio precedente) all'ID contenitore gestito dall'agente.

Decompressione di aggregazioni di attività per ogni passaggio

Quando l'agente esegue un processo, scarica prima di tutto tutti i bundle di attività richiesti dai passaggi del processo. In genere, per le prestazioni, decomprime le attività una sola volta per ogni processo anche se l'attività viene usata in più passaggi. Se si hanno dubbi sulla modifica del codice non attendibile che modifica il contenuto decompresso, è possibile evitare un po ' di prestazioni facendo in modo che l'agente decomprima l'attività su ogni utilizzo. Per abilitare questa modalità, passare --alwaysextracttask quando si configura l'agente.

Miglioramento della sicurezza delle release mediante la limitazione dell'ambito dei token di accesso

Basandosi sull'iniziativa per migliorare le impostazioni di sicurezza per Azure Pipelines, è ora supportata la limitazione dell'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 richiamare azure DevOps. Ad esempio, si usa il token di accesso per ottenere il codice sorgente, scaricare artefatti, caricare log, risultati dei test o effettuare chiamate REST in Azure DevOps. Viene generato un nuovo token di accesso per ogni processo e scade al termine del processo.

Con questo aggiornamento, si migliora la sicurezza della pipeline limitando l'ambito dei token di accesso ed estendendolo alle versioni classiche.

Questa funzionalità sarà attivata per impostazione predefinita per i nuovi progetti e raccolte. Per le raccolte esistenti, è necessario abilitarla in Impostazioni pipeline di > raccolta. > > Limitare l'ambito di autorizzazione del processo al progetto corrente per le pipeline di versione. Altre informazioni qui.

Miglioramenti all'API dell'anteprima di YAML

È ora possibile visualizzare in anteprima il file YAML completo di una pipeline senza eseguirlo. È stato anche creato un nuovo URL dedicato per la funzionalità di anteprima. È ora possibile eseguire 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 "Compilazioni code".

Eseguire questo processo successivamente

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

Espressioni modello consentite nel blocco YAML resources

In precedenza, le espressioni in fase di compilazione (${{ }}) non erano consentite nella resources sezione di un file YAML di Azure Pipelines. Con questa versione, questa restrizione è stata revocata per i contenitori. In questo modo è possibile usare il contenuto dei parametri 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.

Controllo sugli aggiornamenti automatici delle attività da Marketplace

Quando si scrive una pipeline YAML, in genere si specifica solo il numero di versione principale delle attività incluse. In questo modo le pipeline accettano automaticamente le aggiunte di funzionalità e le correzioni di bug più recenti. In alcuni casi potrebbe essere necessario eseguire il rollback a una versione precedente di un'attività e con questo aggiornamento è stata aggiunta la possibilità di farlo. È 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 temporanea quando si rileva che un'attività più recente interrompe le pipeline. Inoltre, non verrà installata una versione precedente di un'attività dal Marketplace. Deve essere già presente 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 di Node 10 in agenti e attività

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

Miglioramento della conversione YAML nella finestra di progettazione di compilazione classica

Con questa versione viene introdotta una nuova funzionalità di esportazione 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" trovata in precedenza nella finestra di progettazione della compilazione classica. Questa funzione era incompleta perché poteva esaminare solo ciò che l'interfaccia utente Web sapeva sulla compilazione, che talvolta causava la generazione di YAML non corretta. La nuova funzione di esportazione tiene conto esattamente del modo in cui la pipeline verrà elaborata e genera YAML con la massima fedeltà alla pipeline della finestra di progettazione.

Nuova conversione della piattaforma Web - Impostazioni repository

Le due pagine delle impostazioni repository sono state convertite 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, la navigazione per i progetti con un numero considerevole di repository è diventata 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 su cui è impostato il criterio. A questo punto, fare clic sul ramo per visualizzare tutti i criteri senza mai uscire dalla pagina Impostazioni repository.

Selezionare branch per visualizzare i criteri.

A questo punto, quando i criteri vengono ereditati da un ambito superiore a quello con cui si lavora, viene illustrato il punto in cui 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 sono stati ereditati i criteri.

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

Filtri di ricerca per ogni sezione.

Integrazione della gestione del cambiamento di ServiceNow con le pipeline YAML

L'app Azure Pipelines per ServiceNow consente di integrare Azure Pipelines e ServiceNow Change Management. Con questo aggiornamento, si prende in considerazione Azure Pipelines del processo di gestione delle modifiche gestito in ServiceNow oltre alle pipeline YAML.

Configurando il controllo "ServiceNow Change Management" su una risorsa, è ora possibile sospendere l'approvazione della modifica 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 di ServiceNow Change Management

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

Artifacts

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

Stiamo riportando la possibilità per i clienti di creare e gestire feed con ambito raccolta tramite l'interfaccia utente Web sia per i servizi locali che per i servizi ospitati.

È ora possibile creare feed con ambito organizzazione tramite l'interfaccia utente, passando a Artefatti -> Crea feed e scegliendo un tipo di feed all'interno dell'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 linea 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.

Aggiornamento dell'API REST della versione del pacchetto ora disponibile per 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 URI

Nome In Obbligatorio Type 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
versione path TRUE string Versione del pacchetto
progetto path string ID progetto o nome 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
visualizzazioni JsonPatchOperation Visualizzazione a cui verrà aggiunta la versione del pacchetto

Per altre informazioni, vedere la documentazione dell'API REST durante l'aggiornamento.

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