Note sulla versione di Azure DevOps Server 2022 Update 2
| Requisiti di sistema della community | degli sviluppatori e condizioni | di licenza di compatibilità | DevOps Blog | SHA-256 Hash |
In questo articolo sono disponibili informazioni sulla versione più recente per Azure DevOps Server.
Per altre informazioni sull'installazione o l'aggiornamento di una distribuzione di Azure DevOps Server, vedere Requisiti del server Azure DevOps.
Per scaricare i prodotti Azure DevOps Server, visitare la pagina download di Azure DevOps Server.
L'aggiornamento diretto ad Azure DevOps Server 2022 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 altre informazioni, vedere la pagina Installa.
Data di rilascio di Azure DevOps Server 2022 Update 2 Patch 2: 12 novembre 2024
| file | Hash SHA-256 |
|---|---|
| devops2022.2patch2.exe | 70930BE091607B490890A48C250DAB6C2087F7F610CC695C9C632C679A491D23 |
È 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
Nota
Azure DevOps Server 2022.2 è stato nuovamente rilasciato per risolvere un problema relativo al caricamento dei nomi di Teams. Il problema è stato segnalato nel post di blog azure DevOps Server 2022.2 RTW. Se è stata installata la versione di Azure DevOps Server 2022.2 rilasciata il 9 luglio, è possibile installare Patch 1 per Azure DevOps Server 2022.2 per risolvere il problema. La patch 1 non è necessaria se si installa Azure DevOps Server 2022.2 per la prima volta dall'aggiornamento dei collegamenti di download per includere la correzione.
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à spoofing del server Azure DevOps
- CVE-2024-35267: vulnerabilità spoofing del server Azure DevOps
- 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 della data non corretta nella notifica tramite posta elettronica della richiesta pull 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 Le casse cargo
- Nuova esperienza di directory dashboard
- Copia rapida e importazione con piano di test o ID suite
È anche possibile passare a singole sezioni per visualizzare tutte le nuove funzionalità per ogni servizio:
Generali
Attività Pubblica risultati test
L'attività Pubblica risultati test supporta ora gli allegati di esecuzione 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
- Ottenere i servizi remoti offerti dal frame 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
});
Boards
Limiti per i percorsi di area e iterazione
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
Nuovo "Criterio 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, l'approvazione implicita del primo commit dell'utente A (quando è stata creata la richiesta pull) e il criterio appena introdotto avrà esito positivo. 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 il criterio appena introdotto abbia esito positivo, l'iterazione non approvata quattro deve essere approvata dall'utente B, C o da qualsiasi altro utente che non ha apportato alcuna modifica alla richiesta pull.
Nota
Si verifica un problema noto per cui i criteri dei rami accettano un gruppo, configurato come revisore, come entità di approvazione. Si supponga di disporre di un'approvazione necessaria eseguita da qualsiasi utente del gruppo G. L'utente A è membro di tale gruppo G. Dopo che l'utente A fornisce l'approvazione come nell'immagine precedente (dopo la quinta iterazione), l'approvazione del gruppo G approva la modifica eseguita dall'utente A. Questo non è previsto e verrà risolto nella versione RTW.
Supporto di filtri senza BLOB e senza albero
Importante
La funzionalità è disabilitata per impostazione predefinita. Per abilitare la funzionalità, eseguire la query seguente nel database di configurazione:
exec prc_SetRegistryValue 1,'#\FeatureAvailability\Entries\Git.EnablePartialClone\AvailabilityState\', 1
Azure DevOps supporta ora due filtri aggiuntivi durante la clonazione/recupero. Di seguito sono riportati i seguenti: --filter=blob:none e --filter=tree:0 La prima opzione (clone senza BLOB) viene usata meglio per lo sviluppo regolare, mentre la seconda opzione (clone senza albero) è più adatta per quei casi in cui si elimina il clone dopo, ad esempio eseguendo una compilazione.
Deprecazione 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 ).
Pipeline
Impedire esecuzioni impreviste della pipeline
Oggi, se la pipeline YAML non specifica una trigger sezione, viene eseguita per le modifiche di cui è stato eseguito il push nel repository. Ciò può creare confusione per il motivo per cui una pipeline è stata eseguita e causare 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 il timeout dei controlli
Quando si verifica il timeout delle approvazioni e dei controlli, la fase a cui appartiene viene ignorata. Anche le fasi che hanno una dipendenza dalla fase ignorata vengono ignorate.
A questo punto è possibile riprovare a una fase quando le approvazioni e verifica il timeout. 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 controlli seguenti sulla connessione al servizio: approvazione, controllo orario di ufficio e controllo richiama funzione di Azure (per applicare un ritardo tra aree diverse).
Si supponga ora di dover eseguire una distribuzione di hotfix. Si 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 ignorare l'esecuzione di approvazioni, orari di ufficio, richiamare la funzione di Azure e richiamare i controlli dell'API REST.
Ignorare un'approvazione.
Ignorare il controllo orario di ufficio.
Ignorare il controllo Richiama funzione di Azure. Ignorare il controllo orario di ufficio.
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 i controlli delle funzioni di Azure
Si supponga di distribuire il sistema in più fasi. Prima di distribuire la seconda fase, è presente un controllo Approvazione e Richiama funzione di Azure che esegue un controllo di integrità nella parte già distribuita del sistema.
Quando si esamina la richiesta di approvazione, si nota che il controllo di integrità è stato eseguito due giorni prima. In questo scenario, potrebbe essere presente un'altra distribuzione che ha interessato il risultato del controllo della integrità.
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.
Nota
È possibile rieseguire un controllo solo se si è un amministratore della risorsa in cui sono stati definiti i controlli.
Supporto per il server aziendale GitHub 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 Richiedi modello consente di imporre che una pipeline si estenda da un set di modelli approvati prima di accedere a una risorsa protetta, ad esempio 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 fino alla parità con le connessioni al servizio o i 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 l'apertura di 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.
Convalida YAML migliorata
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 è ortografia. 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 è possibile usare come destinazione con le distribuzioni 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 approvazioni
È stata migliorata l'individuazione delle approvazioni assegnate a un utente includendo i gruppi a cui appartiene l'utente nei risultati della ricerca.
Le approvazioni contengono ora informazioni sull'esecuzione della pipeline a cui appartengono.
Ad esempio, la chiamata https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending ALL'API REST GET seguente 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 dall'agente della pipeline e dai processi figlio, incluse le attività eseguite in un processo.
Se si sospetta che il processo della pipeline possa verificarsi in vincoli di risorse, abilitare i log dettagliati 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 supporta ora Alpine Linux versioni 3.13 e successive. Alpine Linux è un'immagine di contenitore (base) molto diffusa. È 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 uno strumento di esecuzione, con Node.js usate 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 sul processore Apple non necessitano dell'esecuzione di Rosetta.
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 l'attività Distribuzione modelli 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 risolve i vincoli di dimensione 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 nella servizio app, le attività AzureRmWebAppDeploymentV3/4 usano l'autenticazione con ID Entra di Microsoft per eseguire distribuzioni nell'endpoint Kudu servizio app. Questa operazione richiede una versione recente di msdeploy.exe installata nell'agente, che è il caso negli agenti ospitati windows-2022/windows-latest (vedere le informazioni di riferimento sulle attività).
Override disabilitato dello stato dei criteri di code coverage su Non riuscito quando la compilazione ha esito negativo
In precedenza, lo stato dei criteri di code coverage è stato sottoposto a override su "Non riuscito" se la compilazione nella richiesta pull ha avuto esito negativo. Si tratta di un blocco per alcuni di voi che hanno avuto la compilazione come controllo facoltativo e i criteri di code coverage come controllo obbligatorio per le richieste pull, causando il blocco delle richieste pull.
A questo momento, i criteri di code coverage non verranno sottoposti a override su "Non riuscito" se la compilazione non riesce. Questa funzionalità verrà abilitata per tutti i clienti.
Artifacts
Introduzione al supporto di Azure Artifacts per Le crates 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. Se la transizione non è stata eseguita, si inizierà presto a ricevere avvisi nelle pipeline. 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 supporta npm audit ora i comandi 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 altre informazioni, vedere Usare il controllo npm per rilevare e correggere le vulnerabilità dei pacchetti.
Creazione di report
Nuova esperienza di directory 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à. Provare ora e segnalare cosa si ritiene 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 code coverage viene visualizzata quando viene attivato o disattivato il pulsante Modalità visualizzazione cartelle. In questa modalità è possibile eseguire il drill-down e visualizzare il code coverage per il sottoalbero selezionato. Usare l'interruttore per passare tra le visualizzazioni nuove e precedenti.
Test Plans
Copia rapida e importazione con piano di test o ID suite
È ora possibile gestire più piani di test in Piani di test di Azure con facilità. Riconoscere 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, sono stati eseguiti 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.