Condividi tramite


Miglioramenti dell'integrazione e degli aggiornamenti del servizio Azure DevOps

Per garantire che l'ambiente Azure DevOps rimanga sicuro, vengono apportati aggiornamenti del servizio chiave. Ciò include la fine del supporto per le nuove registrazioni di app OAuth a partire da aprile 2025, anche se le app esistenti continueranno a funzionare fino al ritiro completo nel 2026. Inoltre, l'indicazione del nome del server (SNI) sarà necessaria per tutte le connessioni HTTPS a partire dal 23 aprile 2025, insieme agli aggiornamenti dei criteri di archiviazione della versione di Team Foundation in Azure Repos.

Oltre a questi aggiornamenti, siamo lieti di annunciare i miglioramenti più recenti nell'integrazione di Azure Boards e GitHub, semplificando il collegamento di rami, richieste pull e commit agli elementi di lavoro. Inoltre, pipeline offre ora una maggiore visibilità sulle dipendenze di fase YAML, consentendo ai team di gestire flussi di lavoro più complessi con maggiore efficienza.

Dai un'occhiata alle note di rilascio per i dettagli.

Generale

Azure Boards:

Azure Repos

Azure Pipelines

Piani di test di Azure:

Generale

Nessuna nuova app OAuth di Azure DevOps a partire da aprile 2025

A partire da aprile 2025, non sono più supportati le nuove registrazioni delle app OAuth di Azure DevOps. Si tratta di un primo passo verso la visione a lungo termine del ritiro della piattaforma OAuth di Azure DevOps. È consigliabile che tutti gli sviluppatori che creano applicazioni sulle API REST di Azure DevOps esplorino invece Microsoft Identity Platform e registrino una nuova applicazione Entra .

Tutte le app OAuth di Azure DevOps esistenti continueranno a funzionare fino al ritiro ufficiale della piattaforma nel 2026. Per altre informazioni, vedere il post di blog qui.

Indicazione del nome del server (SNI) ora obbligatoria per Azure DevOps Services

A partire dal 23 aprile 2025, è necessaria l'indicazione del nome del server (SNI) in tutte le connessioni HTTPS in ingresso ad Azure DevOps Services.

SNI è un'estensione del protocollo TLS che consente ai client di specificare il nome host a cui si connettono. Tutti i browser moderni e il software client supportano SNI e lo usano per impostazione predefinita, garantendo una transizione senza problemi per la maggior parte degli utenti. Infatti, più di 99,995% del traffico dei clienti che raggiungono i nostri server è pronto per SNI.

Tuttavia, alcuni software client potrebbero non essere compatibili con SNI a causa di vari fattori, ad esempio obsoleti, librerie di rete non configurate correttamente, runtime o sistemi operativi. I problemi possono verificarsi anche da proxy o firewall NGFW. Gli strumenti seguenti usati con Azure DevOps possono essere interessati dai problemi di SNI:

  • Client Git
  • Plug-in e estensioni dell'IDE (Team Explorer Everywhere)
  • Software in esecuzione in versioni Java precedenti che non supportano SNI (Java 6 e versioni precedenti) o che non hanno SNI abilitato per impostazione predefinita (alcune versioni di Java 7 e 8)
  • Versioni precedenti del browser (vedere https://caniuse.com/sni)

I problemi SNI si manifestano in genere in base a errori di connessione, ad esempio:

  • ERR_SSL_PROTOCOL_ERROR (Errore del protocollo SSL), ERR_CERT_COMMON_NAME_INVALID (Nome comune del certificato non valido)
  • javax.net.ssl.SSLHandshakeException, javax.net.ssl.SSLException
  • Non è stato possibile stabilire una relazione di trust per il canale sicuro SSL/TLS

È possibile convalidare la compatibilità SNI del sistema chiamando l'endpoint di stato di Azure DevOps, configurato per richiedere SNI. Se questa chiamata ha esito positivo, indica che l'host, incluso il sistema operativo e l'ambiente di rete, è compatibile con SNI. Per istruzioni dettagliate su come eseguire il test, visitare il post di blog.

Azure Boards (Pannelli di Azure)

Integrazione di GitHub: miglioramenti nel collegamento a commit, rami e pull request

Microsoft sta migliorando continuamente l'integrazione di Boards e GitHub per chiudere le lacune nell'usabilità e allinearsi all'esperienza con cui si ha familiarità con Azure Repos.

Con questo aggiornamento sono stati introdotti diversi miglioramenti per semplificare il modo in cui rami, richieste pull e commit sono collegati agli elementi di lavoro:

  • Quando un ramo GitHub è collegato a un elemento di lavoro, tutte le richieste pull associate verranno ora collegate automaticamente. Non è necessario usare manualmente AB#.

  • Una volta unita una richiesta pull, il commit di merge verrà collegato automaticamente all'elemento di lavoro.

  • Se il ramo viene eliminato dopo l'unione della richiesta pull, il collegamento al ramo verrà rimosso automaticamente dall'elemento di lavoro.

Questi miglioramenti semplificano il monitoraggio dello stato di avanzamento dello sviluppo e la manutenzione delle associazioni aggiornate degli elementi di lavoro up-to.

Miglioramenti nell'integrazione di gif nei Github Boards.

Integrazione di GitHub: mostra lo stato di compilazione per le pipeline YAML

Ci impegniamo a raggiungere la parità delle funzionalità tra YAML e pipeline classiche. Una funzionalità chiave mancante era la possibilità di fornire un collegamento "Integrato nella compilazione" quando il repository è ospitato in GitHub. Con la versione più recente, è stato risolto questo divario aggiungendo un'opzione nelle impostazioni della pipeline YAML per verificare:

Al termine della compilazione, il collegamento corrispondente verrà visualizzato automaticamente sugli elementi di lavoro associati, migliorando la traccia complessiva della tracciabilità.

Limiti dei piani di consegna aumentati

In precedenza, i piani di recapito per progetto erano limitati a 1.000. Con questo aggiornamento, abbiamo aumentato il numero massimo di piani di consegna per progetto a 1.500. Per altre informazioni sull'aggiunta e la modifica dei piani di recapito, vedere la documentazione qui.

Azure Repos

Modifiche ai criteri di check-in TFVC

Nuova versione (19.254) del pacchetto NuGet Microsoft.TeamFoundationServer.ExtendedClient

Il pacchetto NuGet Microsoft.TeamFoundationServer.ExtendedClient è stato aggiornato con nuove classi e metodi di criteri TFVC.

Modifiche dei criteri

Stiamo apportando modifiche alla modalità di memorizzazione dei criteri di check-in di TFVC in Azure DevOps, il che comporta anche aggiornamenti nel modo in cui NuGet Microsoft.TeamFoundationServer.ExtendedClient comunica con il servizio.

Se il progetto TFVC utilizza i criteri di check-in, migrare tali criteri al nuovo formato. Esistono due modi per eseguire questa operazione:

  1. Uso di Visual Studio.

Avvertimento

Conseguenze certe e pericolose di un'azione. Assicurati di aggiornare Visual Studio all'ultima versione prima di procedere (VS 2022, VS 2019 e VS 2017 con versioni minime 17.14 Preview 3, 17.13.6, 17.12.7, 17.10.13, 17.8.20, 16.11.46, 15.9.72 supportano le nuove politiche).

Per creare nuovi criteri, l'amministratore del progetto di Visual Studio deve aprire Impostazioni -> Progetto Team -> Controllo del codice sorgente -> Criteri di registrazione e aggiungere nuovi criteri (senza contrassegno "Obsoleto") con gli stessi parametri di quello precedente:

  1. Se si usa l'implementazione personalizzata di Microsoft.TeamFoundationServer.ExtendedClient per comunicare con il server, seguire la guida alla migrazione.

La migrazione è necessaria per garantire la compatibilità del check-in TFVC con le versioni future di Azure DevOps. Per il momento, sia i vecchi (obsoleti) che i nuovi criteri rimangono validi e funzionali. Per informazioni sui piani futuri, vedere il post di blog.

Miglioramento dell'API GetRepository

È stata aggiunta creationDate la proprietà alla risposta dell'API Repository - Get Repository che restituisce la data di creazione del repository. La proprietà è disponibile nelle versioni 7.2-preview dell'API e versioni successive.

Miglioramento dell'API delle interrogazioni delle richieste pull

È stata introdotta una nuova Label proprietà nella risposta dell'API Pull Request Query - Get. È ora possibile specificare se includere etichette (tag) per le richieste pull correlate in ogni query. È disponibile una nuova Include proprietà - se impostata su Etichette, la risposta includerà etichette per le pull request specificate. Se lasciato come null, le etichette non verranno incluse. Per evitare errori imprevisti, assicurarsi che NotSet non sia assegnato in modo esplicito. Ciò comporterà Bad Request.

Annotazioni

L'utilizzo delle risorse di arricchimento delle etichette dipende dal numero di etichette assegnate e dalla relativa lunghezza. La richiesta di etichette può influire sulla limitazione del traffico e aumentare il carico di rete. Per ottimizzare le prestazioni, è consigliabile evitare richieste di etichette non necessarie.

Esempio di payload della richiesta:

{
    "queries": [
        {
            "type": "lastMergeCommit",
            "include": "Labels",
            "items": [ 
                "0d6c9b2b524113113fced41aecbf8631a4649dec"
            ]
        },
        {
            "type": "lastMergeCommit",
            "items": [
                "b524113113f0dd41aecbf8631a4649dec6c9b2ce"
            ]
        }
    ]
}

Azure Pipelines

Maggiore visibilità sulle dipendenze della fase della pipeline YAML

Le pipeline YAML offrono flessibilità per la gestione di flussi di lavoro complessi, ma la visualizzazione delle dipendenze delle fasi è stata una sfida, in particolare nelle distribuzioni in più aree.

Non è sempre stato chiaro il modo in cui le fasi sono connesse. Ad esempio, per determinare se CUS3 dipende da WUS1 oltre a WUS2 e WUS3, è necessario esaminare direttamente il codice YAML.

Con questo sprint, le dipendenze di fase vengono ora visualizzate quando viene espansa una fase, fornendo informazioni immediate sull'ordine di esecuzione e sui requisiti upstream.

Nuova CDN del agente

Poiché la rete CDN Edgio viene ritirata, verrà ritirato anche l'URL di dominio di proprietà di Edgio https://vstsagentpackage.azureedge.net . Verrà aggiunto un nuovo URL https://download.agent.dev.azure.com di dominio supportato dalla nuova rete CDN. Assicurarsi di aggiungere questo nuovo URL di dominio all'elenco di elementi consentiti del firewall. I download dei pacchetti dell'agente per gli agenti self-hosted avranno esito negativo dopo la rimozione dell'URL di dominio precedente. Per altri dettagli, vedere il post .

Il nodo 16 verrà rimosso dai pacchetti degli agenti di pipeline-*

Le attività dell'agente possono essere implementate in PowerShell o Node. L'agente viene fornito con più versioni di Node che le attività possono utilizzare.

Man mano che vengono rilasciate nuove versioni di Node, le attività vengono aggiornate per l'uso di nuove versioni di Node. Gli ambienti di runtime sono integrati nell'agente.

Quando le versioni di Node escono dalla finestra di manutenzione upstream, alcune attività pipeline dipendono comunque da essa. Azure DevOps aggiorna le attività supportate in una versione di Node supportata. Le attività di terze parti potrebbero comunque richiedere l'esecuzione di versioni precedenti di Node.

Per soddisfare questo problema, sono disponibili due tipi di pacchetti dell'agente pipeline:

Pacchetti Versioni di Node Descrizione
vsts-agent-* 6, 10, 16, 20 Include tutte le versioni di Node che possono essere usate come gestore di esecuzione delle attività
pipelines-agents-* 20 Include solo le versioni recenti di Node. L'obiettivo di questi pacchetti è non includere alcuna versione end-of-life di Node.

Se si vuole eseguire un'attività che richiede il gestore di esecuzione del nodo 16 in un agente che non dispone di Node 16 in bundle, è possibile installare il gestore di esecuzione inserendo l'attività NodeTaskRunnerInstaller@0 nella pipeline:

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 16

Piani di test di Azure

Ritiro della registrazione delle azioni e passaggio alla registrazione dello schermo

Il client desktop di Azure Test Runner si basa su Problem Steps Recorder (PSR), uno strumento introdotto in Windows 7 che è ora deprecato nelle versioni più recenti di Windows. Di conseguenza, la funzionalità di registrazione delle azioni nel test runner desktop potrebbe non funzionare più nei futuri aggiornamenti.

Per garantire un rilevamento dei test ininterrotto, è consigliabile passare alla registrazione dello schermo nel runner Web, Test & Feedback Extension, che offre un modo moderno e affidabile per acquisire e gestire i passaggi di test. Se è necessaria assistenza per la transizione all'estensione test e feedback, contattare il team di supporto.

Sospendere automaticamente l'esecuzione dei test manuali

Non perdere mai i progressi delle tue esecuzioni di test con l'opzione di pausa automatica dei casi di test. Questa nuova funzionalità sospende automaticamente l'esecuzione del test case se il lavoro viene interrotto, garantendo che il progresso parziale venga salvato senza la necessità di sospendere manualmente. Sia che ci si allontani o si chiuda la sessione, è possibile riprendere facilmente il test case proprio dove è stato interrotto, riducendo il rischio di perdita di dati e migliorando il flusso di lavoro. Semplificando il processo di sospensione e ripresa, la sospensione automatica consente di rimanere concentrati sui test senza doversi preoccupare di perdere lo stato di avanzamento. Provaci e inviaci un messaggio di posta elettronica cosa pensi!

Gif per dimostrare il passo di annullamento del test nel runner web e desktop.

Passaggi successivi

Annotazioni

Queste funzionalità verranno implementate nelle prossime due o tre settimane.

Passare ad Azure DevOps e dare un'occhiata.

Come fornire commenti e suggerimenti

Ci piacerebbe sentire ciò che pensi a queste funzionalità. Usa il menu di aiuto per segnalare un problema o fornire un suggerimento.

Inviare un suggerimento

È anche possibile ottenere consigli e risposte alle domande della community su Stack Overflow.

Grazie

Silviu Andrica