Note sulla versione di Azure DevOps Server 2022 Update 2

| Community degli Sviluppatori | Requisiti di Sistema e Compatibilità | Termini di Licenza | Blog DevOps | Hash SHA-256 |

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

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

Data di rilascio di Azure DevOps Server 2022 Update 2 Patch 5: 8 aprile 2025

È stata rilasciata la patch 5 per Azure DevOps Server 2022 Update 2 per includere:

• In precedenza, l'agente Di Azure DevOps usava la rete CDN Edgio con l'endpoint vstsagentpackage.azureedge.net. Nell'ambito del ritiro di Edgio, il *.azureedge.net dominio viene rimosso. Per garantire la disponibilità continua, è stata eseguita la migrazione a una rete CDN supportata da Akamai con un nuovo endpoint download.agent.dev.azure.com. Questa patch include le modifiche necessarie per recuperare i file binari dell'agente dal nuovo endpoint della rete CDN, eseguendo così la migrazione dall'endpoint della rete CDN precedente.

Data di rilascio di Azure DevOps Server 2022 Update 2 Patch 4: 11 marzo 2025

È stata rilasciata patch 4 per Azure DevOps Server 2022 Update 2 per includere:

• Aggiornare le attività a seguito dell’abbandono del servizio CDN Edgio. Per ulteriori dettagli, consulta l'articolo del blog Switching CDN providers.
• Aggiornata la dipendenza Mermaid.

Data di rilascio di Azure DevOps Server 2022 Update 2 Patch 3: 11 febbraio 2025

È stata rilasciata patch 3 per Azure DevOps Server 2022 Update 2 per includere:

• Aggiornamenti in Artifacts per aggiungere Python Enhancement Proposals (PEPs) 685. Questo aggiornamento risponde ai commenti e suggerimenti condivisi nella community degli sviluppatori .

Data di rilascio di Azure DevOps Server 2022 Update 2 Patch 2: 12 novembre 2024

È stata rilasciata la patch 2 per Azure DevOps Server 2022 Update 2 per includere un aggiornamento a una dipendenza vulnerabile.

Data di rilascio di Azure DevOps Server 2022.2 RTW: 9 luglio 2024

Riepilogo delle novità di Azure DevOps Server 2022.2 RTW

Azure DevOps Server 2022.2 RTW è un rollup delle correzioni di bug. Include tutte le funzionalità di Azure DevOps Server 2022.2 RC rilasciate in precedenza. È possibile installare direttamente Azure DevOps Server 2022.2 o eseguire l'aggiornamento da Azure DevOps Server 2020, 2019 o Team Foundation Server 2015 o versione successiva. In questa versione sono stati risolti i problemi e le vulnerabilità seguenti:

• CVE-2024-35266: vulnerabilità di spoofing del server Azure DevOps
• CVE-2024-35267: vulnerabilità di spoofing in Azure DevOps Server
• Ticket di feedback della community degli sviluppatori: la versione dell'agente non viene aggiornata dopo l'aggiornamento ad Azure DevOps Server 2022.1 e l'uso dell'agente di aggiornamento nella configurazione del pool di agenti
• Ticket di feedback della Community degli Sviluppatori: Problema con il caricamento della pagina di configurazione del Team
• Ticket di feedback della community degli sviluppatori: Correzione della gestione errata delle date nelle notifiche e-mail dei pull request per determinati formati regionali

Data di rilascio di Azure DevOps Server 2022 Update 2 RC: 7 maggio 2024

Azure DevOps Server 2022.2 RC include molte nuove funzionalità. Tra le caratteristiche principali:

• Limiti per i percorsi di area e iterazione
• Ignorare le approvazioni e i controlli nelle pipeline
• Convalida YAML migliorata
• Supporto di Azure Artifacts per i crate Cargo
• Nuova esperienza di directory dashboard
• Copia rapida e importazione con ID del piano di test o suite

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

• Generali
• Schede
• Repos
• Pipeline
• Manufatti
• Rapporto

Generale

Attività Pubblica i risultati dei test

L'attività di pubblicazione dei risultati dei test ora supporta gli allegati delle esecuzioni dei test per il formato del report JUnit.

Nuova versione di Azure DevOps Web Extension SDK

Con questo aggiornamento viene rilasciata una nuova versione di Azure DevOps Web Extension SDK. L'SDK client consente alle estensioni Web di comunicare con il frame host. Può essere usato per:

• Notificare all'host che l'estensione viene caricata o presenta errori
• Ottenere informazioni contestuali di base sulla pagina corrente (informazioni sull'utente corrente, sull'host e sull'estensione)
• Ottenere informazioni sul tema
• Ottenere un token di autorizzazione da usare nelle chiamate REST ad Azure DevOps
• Accedere ai servizi remoti offerti dal quadro host

Per informazioni di riferimento complete sull'API, vedere la documentazione del pacchetto azure-devops-extension-sdk. Questa nuova versione offre il supporto per i moduli seguenti:

• Supporto del modulo ES: SDK supporta ora i moduli ES (ECMAScript) oltre ai moduli AMD (Asynchronous Module Definition) esistenti. È ora possibile importare SDK usando la sintassi del modulo ES, che offre miglioramenti delle prestazioni e riduce le dimensioni dell'applicazione.

• Compatibilità con le versioni precedenti per i moduli AMD: il supporto esistente per i moduli AMD rimane intatto. Se il progetto usa moduli AMD, è possibile continuare a usarli come prima senza apportare modifiche.

Come usare:

Per i moduli ES, è possibile importare i moduli usando l'istruzione import:

import * as SDK from 'azure-devops-extension-sdk';
// Use the module here

Se si usano i moduli AMD, è possibile continuare a importare l'SDK usando la require funzione :

require(['azure-devops-extension-sdk'], function(SDK) {

  // Use the module here
});

Bacheche

Limiti per percorsi di iterazione e area

I limiti svolgono un ruolo importante nel mantenere l'integrità e l'efficienza di un servizio globale di grandi dimensioni. Con questa versione vengono introdotti limiti rigidi di 10.000 per progetto per entrambi i percorsi di area e iterazione. Per altre informazioni sui diversi limiti del servizio, visitare la pagina Rilevamento lavoro, processo e limiti del progetto.

Controlli di sviluppo e distribuzione

A questo punto, i controlli Sviluppo e/o Distribuzione vengono rimossi dall'elemento di lavoro, a seconda della configurazione del progetto. Ad esempio, è possibile configurare le impostazioni del progetto per disattivare Repos e/o Pipeline.

Quando si passa all'elemento di lavoro, i controlli Sviluppo e distribuzione corrispondenti verranno nascosti dal modulo.

Se si decide di connettere un repository GitHub ad Azure Boards, verrà visualizzato il controllo Sviluppo per i repository GitHub.

Repos

Nuova "politica del ramo" che impedisce agli utenti di approvare le proprie modifiche

Per migliorare il controllo sulle modifiche approvate dall'utente e soddisfare i requisiti normativi/di conformità più rigorosi, è possibile impedire all'utente di approvare le proprie modifiche, a meno che non sia consentito in modo esplicito.

L'utente con la possibilità di gestire i criteri dei rami può ora passare all'opzione "Richiedi almeno un'approvazione per ogni iterazione" in "Quando vengono inserite nuove modifiche". Quando questa opzione è selezionata, è necessario almeno un voto di approvazione per l'ultima modifica del ramo di origine. L'approvazione dell'utente non viene conteggiata rispetto a qualsiasi iterazione precedente non approvata di cui è stato eseguito il push da tale utente. Di conseguenza, è necessaria un'ulteriore approvazione per l'ultima iterazione da parte di un altro utente.

L'immagine seguente mostra la richiesta pull creata dall'utente A e altri 4 commit (iterazioni) effettuati a tale richiesta pull dagli utenti B, C, A e C. Al termine della seconda iterazione (commit eseguito dall'utente B), l'utente C lo ha approvato. In quel momento, ciò implicava l'approvazione del primo commit dell'utente A (quando è stata creata la richiesta di pull) e il criterio appena introdotto avrà successo. Dopo la quinta iterazione (ultimo commit dell'utente C), l'approvazione è stata eseguita dall'utente A. Questa approvazione implicita per il commit precedente eseguito dall'utente C, ma non implicava l'approvazione per il secondo commit eseguito dall'utente A nella quarta iterazione. Per far sì che la nuova politica abbia successo, l'iterazione quattro non approvata deve essere approvata dall'utente B, C o da qualsiasi altro utente che non ha apportato alcuna modifica alla richiesta di pull.

Supporto di filtri senza BLOB e senza albero

exec prc_SetRegistryValue 1,'#\FeatureAvailability\Entries\Git.EnablePartialClone\AvailabilityState\', 1

Azure DevOps supporta ora due filtri aggiuntivi durante la clonazione/recupero. Questi sono: --filter=blob:none e --filter=tree:0 La prima opzione (clone senza BLOB) è la migliore per lo sviluppo regolare, mentre la seconda opzione (clone senza albero) si adatta meglio a quei casi in cui si elimina il clone dopo, ad esempio, aver eseguito una compilazione.

Obsolescenza di SSH-RSA

Azure Repos offre due metodi per consentire agli utenti di accedere a un repository Git in Azure Repos - HTTPS e SSH. Per usare SSH, è necessario creare una coppia di chiavi usando uno dei metodi di crittografia supportati. In passato, abbiamo supportato solo SSH-RSA e abbiamo chiesto agli utenti di abilitare SSH-RSA qui.

Con questo aggiornamento, viene annunciata la deprecazione di SSH-RSA come metodo di crittografia supportato per la connessione ad Azure Repos tramite SSH. Per altri dettagli, vedere il post di blog End of SSH-RSA support for Azure Repos (Fine del supporto SSH-RSA per Azure Repos ).

Le pipeline

Impedire esecuzioni non intenzionali delle pipelines

Oggi, se la pipeline YAML non specifica la sezione trigger, viene eseguita per ogni modifica eseguita nel repository. Ciò può creare confusione sul motivo per cui una pipeline è stata eseguita e portare a molte esecuzioni impreviste.

È stata aggiunta un'impostazione Pipelines a livello di progetto e raccolta di progetti denominata Disable implicit YAML CI trigger che consente di modificare questo comportamento. Se manca la sezione trigger, è possibile scegliere di non attivare le pipeline.

Ripetere una fase quando le approvazioni e i controlli vanno in timeout.

Quando si verifica il timeout delle approvazioni e dei controlli, la fase a cui appartengono viene ignorata. Anche le fasi che hanno una dipendenza dalla fase saltata sono anche saltate.

Ora è possibile riprovare una fase quando le approvazioni e le verifiche superano il tempo limite. In precedenza, ciò era possibile solo quando si verificava il timeout di un'approvazione.

Ignorare approvazioni e controlli

Le approvazioni e i controlli consentono di proteggere l'accesso a risorse importanti, ad esempio connessioni al servizio, repository o pool di agenti. Un caso d'uso comune consiste nell'usare approvazioni e controlli durante la distribuzione nell'ambiente di produzione e si vuole proteggere la connessione al servizio ARM.

Si supponga di aver aggiunto i seguenti controlli alla connessione al servizio: un controllo di approvazione, un controllo dell'orario di lavoro e un controllo di invocazione della funzione Azure (per applicare un ritardo tra diverse aree).

Ora, immagina di dover eseguire un'implementazione di hotfix. Avvia un'esecuzione della pipeline ma non procede, attende il completamento della maggior parte dei controlli. Non è possibile permettersi di attendere il completamento delle approvazioni e dei controlli.

Con questa versione è stato possibile ignorare le approvazioni e i controlli in esecuzione, in modo da poter completare l'hotfix.

È possibile bypassare l'esecuzione delle approvazioni, degli orari di ufficio, chiamare la funzione Azure e invocare controlli dell'API REST.

Ignorare un'approvazione.

Bypassare il controllo dell'orario di lavoro.

Ignorare il controllo "Richiama" funzione di Azure. Bypassare il controllo dell'orario di lavoro.

Quando un controllo viene ignorato, è possibile visualizzarlo nel pannello dei controlli.

È possibile ignorare un controllo solo se si è un amministratore della risorsa in cui sono stati definiti i controlli.

Rieseguire e invocare i controlli della funzione di Azure

Si supponga di distribuire il sistema in più fasi. Prima di distribuire la seconda fase, viene eseguito un controllo di approvazione e di Invoke Function di Azure che effettua un controllo di integrità sulla parte del sistema già implementata.

Quando si esamina la richiesta di approvazione, si nota che il controllo di integrità è stato eseguito due giorni prima. In questo scenario, potresti essere consapevole di un'altra distribuzione che ha influenzato il risultato della verifica di coerenza.

Con questo aggiornamento è possibile rieseguire Richiamare le funzioni di Azure e richiamare i controlli dell'API REST. Questa funzionalità è disponibile solo per i controlli che hanno avuto esito positivo e non hanno nuovi tentativi.

Supporto per GitHub Enterprise Server nel controllo del modello richiesto

I modelli sono un meccanismo di sicurezza che consente di controllare le fasi, i processi e i passaggi delle pipeline nella raccolta di progetti.

Il Controllo di richiesta modello consente di garantire che una pipeline utilizzi un set di modelli approvati prima di accedere a una risorsa protetta, come un pool di agenti o una connessione al servizio.

È ora possibile specificare i modelli disponibili nei repository gitHub Enterprise Server.

Ruolo di amministratore per tutti gli ambienti

Gli ambienti nelle pipeline YAML rappresentano una risorsa di calcolo in cui si distribuisce l'applicazione, ad esempio un cluster del servizio Azure Kubernetes o un set di macchine virtuali. Forniscono controlli di sicurezza e tracciabilità per le distribuzioni.

La gestione degli ambienti può essere piuttosto complessa. Ciò è dovuto al fatto che, quando viene creato un ambiente, la persona che la crea diventa automaticamente l'unico amministratore. Ad esempio, se si vogliono gestire le approvazioni e i controlli di tutti gli ambienti in modo centralizzato, è necessario chiedere a ogni amministratore dell'ambiente di aggiungere un utente o un gruppo specifico come amministratore e quindi usare l'API REST per configurare i controlli. Questo approccio è noioso, soggetto a errori e non viene ridimensionato quando vengono aggiunti nuovi ambienti.

Con questa versione è stato aggiunto un ruolo di amministratore a livello di hub degli ambienti. In questo modo gli ambienti sono portati allo stesso livello delle connessioni al servizio o dei pool di agenti. Per assegnare il ruolo di amministratore a un utente o a un gruppo, è necessario essere già un amministratore dell'hub di ambienti o un proprietario della raccolta di progetti.

Un utente con questo ruolo di amministratore può amministrare autorizzazioni, gestire, visualizzare e usare qualsiasi ambiente. Ciò include rendere accessibili gli ambienti a tutte le pipeline.

Quando si concede un ruolo di amministratore utente a livello di hub degli ambienti, diventano amministratori per tutti gli ambienti esistenti e per qualsiasi ambiente futuro.

Miglioramento della convalida YAML

Per verificare che la sintassi YAML sia corretta, è possibile usare la funzionalità Convalida dell'editor Web di Azure Pipelines. È quindi importante che questa funzionalità intercetta il maggior numero possibile di problemi YAML.

La convalida YAML è ora più approfondita quando si tratta di espressioni.

Quando si scrivono pipeline YAML, è possibile usare le funzioni per definire i valori delle variabili.

Si supponga di definire le variabili seguenti:

variables:
  Major: '1'
  Minor: '0'
  Patch: $[counter(fromat('{0}.{1}', variables.Major, variables.Minor ), 0)]

La Patch variabile viene definita usando la counter funzione e le altre due variabili. Nel codice YAML precedente la parola format è scritta male. In precedenza, questo errore non è stato rilevato. Ora, la funzionalità Convalida rileverà questo elemento e visualizzerà un messaggio di errore.

Azure Pipelines rileverà definizioni di variabili non corrette a livello di pipeline/fase/processo.

Nelle pipeline YAML è possibile ignorare l'esecuzione della fase usando le condizioni. Gli errori di digitatura possono essere visualizzati anche qui, come nell'esempio seguente.

steps:
- task: NuGetCommand@2
  condition: eq(variable.Patch, 0)
  inputs:
    command: pack
    versioningScheme: byPrereleaseNumber
    majorVersion: '$(Major)'
    minorVersion: '$(Minor)'
    patchVersion: '$(Patch)'

L'attività NuGetCommand viene eseguita solo se il valore della Patch variabile è 0. Anche in questo caso, è presente un errore di ortografia nella condizione e la funzionalità Convalida la visualizzerà.

Azure Pipelines rileverà condizioni YAML non corrette definite a livello di pipeline/fase/processo.

API REST per ambienti

Un ambiente è una raccolta di risorse che puoi usare come destinazioni per i rilasci da una pipeline. Gli ambienti forniscono la cronologia di distribuzione, la tracciabilità per gli elementi di lavoro e i commit e i meccanismi di controllo di accesso.

Sappiamo che si vuole creare ambienti a livello di codice, quindi è stata pubblicata la documentazione per l'API REST.

Miglioramenti all'API REST delle Approvals

È stata migliorata l'individuazione delle approvazioni assegnate a un utente includendo i gruppi a cui appartiene l'utente nei risultati della ricerca.

Adesso, le approvazioni contengono informazioni sull'esecuzione della pipeline a cui appartengono.

Ad esempio, la seguente chiamata GET all'API REST https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&[email protected]&state=pending restituisce

{
    "count": 1,
    "value":
    [
        {
            "id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
            "steps":
            [],
            "status": "pending",
            "createdOn": "2023-11-09T10:54:37.977Z",
            "lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
            "executionOrder": "anyOrder",
            "minRequiredApprovers": 1,
            "blockedApprovers":
            [],
            "_links":
            {
                "self":
                {
                    "href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
                }
            },
            "pipeline":
            {
                "owner":
                {
                    "_links":
                    {
                        "web":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
                        },
                        "self":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
                        }
                    },
                    "id": 73222930,
                    "name": "20231109.1"
                },
                "id": "4597",
                "name": "FabrikamFiber"
            }
        }
    ]
}

I log della pipeline contengono ora l'utilizzo delle risorse

I log della pipeline di Azure possono ora acquisire le metriche di utilizzo delle risorse, ad esempio memoria, utilizzo della CPU e spazio disponibile su disco. I log includono anche le risorse usate tramite l'agente della pipeline e dai processi subordinati, comprese le attività eseguite in un processo di lavoro.

Se sospetti che il processo della pipeline possa incontrare vincoli di risorse, abilita i log dettagliati per fare in modo che le informazioni sull'utilizzo delle risorse vengano inserite nei log della pipeline. Questo funziona su qualsiasi agente, indipendentemente dal modello di hosting.

L'agente di Azure Pipelines ora supporta Alpine Linux

L'agente Pipeline v3.227 ora supporta Alpine Linux versioni 3.13 e successive. Alpine Linux è molto apprezzato come immagine base per container. È possibile trovare l'agente nella pagina delle versioni. Le versioni Alpine Linux dell'agente hanno un prefisso vsts-agent-linux-musl , vsts-agent-linux-musl-x64-3.227.1.tar.gzad esempio .

Le attività di Azure Pipelines usano Node 16

Le attività nella pipeline vengono eseguite usando un runner, con Node.js usato nella maggior parte dei casi. Le attività di Azure Pipelines che usano un nodo come strumento di esecuzione ora usano tutti Node 16. Poiché Node 16 è la prima versione node a supportare in modo nativo il processore Apple, questo completa anche il supporto completo delle attività per macOS nel processore Apple. Gli agenti in esecuzione su Apple silicon non richiedono Rosetta per funzionare.

Poiché la data di fine vita del nodo 16 è stata spostata in avanti, è stato avviato il lavoro per l'esecuzione delle attività con il nodo 20.

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

È possibile usare il task di Distribuzione di template di Azure Resource Manager per creare l'infrastruttura di Azure. In risposta ai commenti e suggerimenti, è stato aumentato il limite di integrazione di Azure Pipelines da 2 MB a 4 MB. Questa operazione verrà allineata alle dimensioni massime dei modelli ARM di 4 MB che risolvono i vincoli di dimensioni durante l'integrazione di modelli di grandi dimensioni.

L'attività AzureRmWebAppDeployment supporta l'autenticazione di Microsoft Entra ID

Le attività AzureRmWebAppDeploymentV3 e AzureRmWebAppDeployment@4 sono state aggiornate per supportare servizio app con l'autenticazione di base disabilitata. Se l'autenticazione di base è disabilitata nel servizio App, delle attività AzureRmWebAppDeploymentV3/4 usano l'autenticazione Microsoft Entra ID per eseguire distribuzioni sull'endpoint Kudu del servizio App. Questa operazione richiede una versione recente di msdeploy.exe installata nell'agente, che è già presente sugli agenti ospitati windows-2022/windows-latest (vedere le informazioni di riferimento sulle attività).

Disabilitazione dell'override dello stato dei criteri di copertura del codice a non riuscito se la compilazione fallisce

In precedenza, lo stato della politica di copertura del codice veniva impostato su "Non riuscito" se la build nella pull request non aveva avuto successo. Questo ha rappresentato un ostacolo per alcuni di voi che avevano la compilazione come controllo facoltativo e la policy di code coverage come controllo obbligatorio per le pull request, causando il blocco delle stesse.

Ora, i criteri di code coverage non verranno sovrascritti a "Non riuscito" se la compilazione fallisce. Questa funzionalità verrà abilitata per tutti i clienti.

Manufatti

Introduzione al supporto di Azure Artifacts per le crate Cargo

Microsoft è lieta di annunciare che Azure Artifacts offre ora il supporto nativo per le casse Cargo. Questo supporto include parità di funzionalità rispetto ai protocolli esistenti, oltre a crates.io disponibile come origine upstream. Gli sviluppatori e i team rust possono ora usare, pubblicare, gestire e condividere le casse Cargo senza problemi, tutto il tempo usando l'infrastruttura affidabile di Azure e rimanendo nell'ambiente Azure DevOps familiare.

Annuncio di deprecazione per le attività della pipeline NuGet Restore v1 e NuGet Installer v0

Se si usano le attività della pipeline NuGet Restore v1 e NuGet Installer v0, passare immediatamente all'attività della pipeline NuGetCommand@2. Inizierai presto a ricevere avvisi nelle tue pipeline se la transizione non è stata eseguita. Se non viene eseguita alcuna azione, a partire dal 27 novembre 2023, le compilazioni genereranno un errore.

Supporto di Azure Artifacts per il controllo npm

Azure Artifacts ora supporta i comandi npm audit e npm audit fix. Questa funzionalità consente agli utenti di analizzare e correggere le vulnerabilità del progetto aggiornando automaticamente le versioni dei pacchetti non sicure. Per ulteriori informazioni, consulta npm audit per rilevare e correggere le vulnerabilità dei pacchetti.

Reportistica

Nuova esperienza nella gestione delle directory del dashboard

Abbiamo ascoltato i commenti e suggerimenti e siamo entusiasti di presentare la nuova esperienza della directory dashboard. Non solo offre una progettazione moderna dell'interfaccia utente, ma consente anche di ordinare in base a ogni colonna, con l'aggiunta della colonna Last Configured . Questa colonna fornisce informazioni più dettagliate sull'utilizzo complessivo del dashboard all'interno della raccolta di progetti. Inoltre, è ora possibile filtrare in base ai dashboard a livello di team o di progetto, consentendo di accedere solo all'elenco di ciò che è necessario visualizzare nascondendo i dashboard che non si desidera visualizzare.

Provalo ora e comunicaci cosa pensi nella community di Azure DevOps

Filtro degli elementi di lavoro

Siamo lieti di annunciare il filtro grafico degli elementi di lavoro. Questa funzionalità consente di passare il puntatore del mouse sul grafico degli elementi di lavoro per una rapida panoramica ed eseguire il drill-down in segmenti di grafico specifici per informazioni dettagliate. Non è più necessario creare query personalizzate per accedere all'esatta porzione di dati necessaria. È ora possibile esaminare gli elementi di lavoro nei grafici degli elementi di lavoro in pochi clic.

Il feedback è prezioso per modellare il futuro di questa funzionalità. Provalo ora e facci sapere cosa ne pensi nella community di Azure DevOps.

Risultati del code coverage per le cartelle

I risultati per il code coverage sono ora disponibili per ogni singolo file e cartella anziché solo come numero di primo livello. La visualizzazione della copertura del codice appare quando viene attivato il pulsante modalità di visualizzazione cartelle. In questa modalità è possibile eseguire il drill-down e visualizzare il code coverage per il sottoalbero selezionato. Usare il pulsante di commutazione per passare tra le visualizzazioni nuove e vecchie.

Piani di Test

"Copia rapida e importazione con ID del piano di test o della suite"

È ora possibile gestire più piani di test in Piani di test di Azure con facilità. Riconoscendo le sfide affrontate in precedenza con i menu a discesa lunghi per l'importazione, la copia o la clonazione di test case - in particolare per piani o suite estesi - abbiamo intrapreso dei passaggi per semplificare il flusso di lavoro.

Siamo lieti di annunciare la funzionalità Test Plan and Suite ID Search (Piano di test e Ricerca ID suite). Immettere il piano di test o l'ID della suite per l'importazione o la copia rapida dei test case senza ritardi. Questo aggiornamento fa parte del nostro impegno continuo per migliorare l'esperienza di gestione dei test, rendendolo più intuitivo e meno dispendioso in termini di tempo.

Aggiornamento per Test Runner di Azure

Microsoft è lieta di condividere che Azure Test Runner è stato aggiornato a una versione più recente. Questo aggiornamento migliora la stabilità e le prestazioni, consentendo di eseguire i test senza interruzioni o ritardi. La versione precedente di Azure Test Runner non è più supportata. Per ottenere prestazioni ottimali e affidabilità delle operazioni di test, è consigliabile eseguire l'aggiornamento alla versione più recente il prima possibile.

Novità

• Maggiore stabilità e prestazioni: sono stati apportati miglioramenti significativi a Test Runner, risolvendo i problemi riscontrati da alcuni utenti. Questo aggiornamento garantisce un processo di test più affidabile, riducendo al minimo le interruzioni del lavoro.
• Richiesta di aggiornamento: per semplificare la transizione alla nuova versione, verrà visualizzata una richiesta di aggiornamento. Ciò garantisce che tutti possano passare facilmente alla versione migliorata per comodità, migliorando la compatibilità e le prestazioni.

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.