Miglioramento della visibilità della distribuzione con ID degli artefatti e viste a livello di fase

Questo sprint migliora la chiarezza della distribuzione di Azure Pipelines visualizzando l'esatto artefatto di compilazione distribuito in ogni esecuzione della pipeline e introducendo una nuova visualizzazione Fasi. Insieme, questi aggiornamenti semplificano la verifica della versione distribuita, della posizione in cui è in esecuzione e dell'avanzamento delle distribuzioni tra gli ambienti

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

Generali

• Anteprima pubblica del server MCP remoto
• Consenti alle estensioni di accedere alle risorse di rete locali
• I token di accesso personali scaduti non possono più essere modificati

Sicurezza avanzata di GitHub per Azure DevOps

• Controlli avanzati dello stato di sicurezza per le richieste pull
• Esportare i risultati dalla panoramica della sicurezza
• Eventi del registro di controllo per le modifiche all'abilitazione della sicurezza avanzata
• Pulizia automatica degli avvisi dalle configurazioni di pipeline obsolete

Azure Boards (Pannelli di Azure)

• Aumento del limite di processi ereditati

Azure Pipelines

• Miglioramento della visibilità della distribuzione continua nelle pipeline YAML
• Cronologia della distribuzione per le fasi

Piani di test di Azure

• Eseguire query e correlare elementi di lavoro tra progetti nei risultati dei test

Generali

Anteprima pubblica del server MCP remoto

Microsoft è lieta di presentare il server MCP di Azure DevOps remoto, ora disponibile in anteprima pubblica. Questo endpoint ospitato consente una perfetta integrazione con Azure DevOps senza la necessità di gestire un server locale. Il supporto è attualmente disponibile in Visual Studio e Visual Studio Code, con client e servizi aggiuntivi, tra cui Microsoft Foundry e Copilot Studio, presto disponibile.

Iniziare è semplice. A seconda degli strumenti in uso, è sufficiente aggiungere le informazioni sul server seguenti a mcp.json.

{
  "servers": {
    "ado-remote-mcp": {
      "url": "https://mcp.dev.azure.com/{organization}",
      "type": "http"
    }
  },
  "inputs": []
}

Sono disponibili opzioni di configurazione aggiuntive per personalizzare la configurazione. Per altre informazioni, vedere la documentazione ufficiale: Server MCP remoto.

Consenti alle estensioni di accedere alle risorse di rete locali

Alcuni Web browser possono bloccare le chiamate da iframe alle risorse nella rete locale, che possono influire sulle organizzazioni di Azure DevOps che si basano sulle estensioni che si connettono ai servizi back-end ospitati nelle reti aziendali interne. Per evitare interruzioni e continuare a usare queste estensioni, le organizzazioni possono consentire alle estensioni di accedere alle risorse nei criteri di sicurezza della rete locale .

Per altre informazioni sui criteri, vedere la documentazione.

I token di accesso personali scaduti non possono più essere modificati

È stato chiuso un divario rilevato nel comportamento del token di accesso personale (PAT) che consentiva la modifica o l'estensione di determinati TOKEN scaduti dopo la data di scadenza. In futuro, le api PAT scadute non possono essere modificate o estese tramite l'interfaccia utente di Azure DevOps o le API PAT nel prodotto Azure DevOps Services.

Questa modifica applica la durata del token reale, riduce il rischio di perdite o di credenziali dimenticate e rende il comportamento pat più semplice e più prevedibile. Consente inoltre ai clienti di soddisfare le aspettative di sicurezza e conformità interne, assicurando che le credenziali non possano persistere silenziosamente oltre la loro durata prevista.

Se un pat scade, creare un nuovo token o rigenerare il token esistente. Usare sempre i PT di breve durata e prendere in considerazione la migrazione all'autenticazione basata su Entra di Microsoft, se supportata.

Sicurezza avanzata di GitHub per Azure DevOps

Controlli avanzati dello stato di sicurezza per le richieste pull

Sicurezza avanzata ora pubblica controlli di stato configurabili che si integrano con il sistema di criteri di ramo predefinito di Azure DevOps. Quando l'analisi della sicurezza avanzata viene eseguita su una richiesta pull, pubblica automaticamente i controlli di stato che possono essere usati come criteri di ramo necessari.

Sono disponibili due nuovi controlli di stato:

• AdvancedSecurity/NewHighAndCritical : ha esito negativo solo quando la richiesta pull introduce nuovi avvisi di gravità alta o critica, ignorando i risultati preesistenti nel ramo di destinazione.
• AdvancedSecurity/AllHighAndCritical : ha esito negativo quando sono presenti avvisi con gravità elevata o critica, inclusi gli avvisi preesistenti nel ramo di destinazione.

I controlli di stato usano il comportamento fail-open: i repository in cui la Sicurezza Avanzata non è abilitata passano automaticamente il controllo, evitando il blocco del flusso di lavoro per i repository non sottoposti a onboarding.

Per usare questi controlli di stato, aggiungerli come criteri di stato necessari nei rami tramite le impostazioni dei criteri di ramo. Per altre informazioni e configurazione, vedere Controlli di stato di sicurezza avanzati.

Esportare i risultati dalla panoramica della sicurezza

È ora possibile esportare i risultati dalla panoramica della sicurezza in un file CSV. Sia le visualizzazioni Rischio che Copertura supportano l'esportazione, offrendo uno snapshot scaricabile del comportamento di sicurezza dell'organizzazione nei repository. La prossima pagina Avvisi, che fornisce informazioni dettagliate su avvisi specifici nell'organizzazione, supporterà anche la funzionalità di esportazione con un massimo di 1.000 avvisi esportati.

Questa funzionalità è disponibile solo tramite l'interfaccia utente in questo momento.

Eventi del log di controllo per le modifiche all'abilitazione della funzionalità di sicurezza avanzata

Azure DevOps registra ora gli eventi del log di controllo ogni volta che le impostazioni di abilitazione di GitHub Advanced Security cambiano. Quando le funzionalità di sicurezza avanzata sono abilitate o disabilitate a livello di repository, progetto o organizzazione, viene acquisito un evento dettagliato nel log di controllo di Azure DevOps.

Le voci del registro di controllo includono l'attore, la data e ora e le impostazioni specifiche modificate, tra cui:

• Sicurezza Avanzata (in bundle) o Piani di Sicurezza del Codice/Protezione dei Segreti (autonomi)
• Configurazione predefinita di CodeQL
• Impostazione predefinita per l'analisi delle dipendenze
• Protezione dei segreti tramite push

Questi eventi offrono visibilità su quando e da chi sono configurate le funzionalità di sicurezza nell'organizzazione, supportando i requisiti di conformità e governance.

Pulizia automatica degli avvisi dalle configurazioni obsolete della pipeline

Sicurezza avanzata ora nasconde automaticamente gli avvisi associati alle configurazioni della pipeline che non sono stati eseguiti in più di 90 giorni. Le impronte digitali degli avvisi in Sicurezza avanzata sono associate a configurazioni di pipeline specifiche, quindi quando viene modificato un processo o una fase della pipeline, gli avvisi associati in precedenza possono diventare orfani se sono stati risolti anche come parte dell'aggiornamento della pipeline.

Con questa modifica, gli avvisi collegati alle configurazioni di pipeline non aggiornate vengono nascosti automaticamente, riducendo il rumore e assicurandosi che i risultati dell'avviso riflettano la configurazione CI/CD corrente. Se si esegue nuovamente una configurazione della pipeline precedentemente obsoleta dopo che gli avvisi sono stati nascosti, gli avvisi aperti in precedenza verranno riattivati come avvisi aperti e attivi. È anche possibile usare l'API di analisi delle eliminazioni per nascondere manualmente gli avvisi associati a configurazioni di pipeline specifiche che non sono più in uso.

Azure Boards (Pannelli di Azure)

Aumento del limite dei processi ereditati

Per supportare meglio le organizzazioni con esigenze complesse di personalizzazione dei processi, è stato raddoppiato il limite per i processi ereditati. Le organizzazioni possono ora creare fino a 256 processi ereditati, aumentati rispetto al limite precedente di 128.

Azure Pipelines

Miglioramento della visibilità della distribuzione continua nelle pipeline basate su YAML

In precedenza era difficile determinare quali elementi sono stati distribuiti in un'esecuzione specifica durante l'uso di Azure Pipelines basate su YAML per scenari di distribuzione continua (CD). In questo sprint, abbiamo migliorato la visibilità degli artefatti tra le esecuzioni della pipeline.

Nella pagina di riepilogo delle esecuzioni della pipeline, è ora possibile visualizzare l'artefatto usato da ogni esecuzione, semplificando la comprensione di quanto distribuito a colpo d'occhio.

Quando si visualizza una singola esecuzione, Azure Pipelines ora visualizza gli artefatti utilizzati in quell’esecuzione in cima alla pagina dei dettagli dell'esecuzione.

Questa funzionalità funziona con gli artefatti della pipeline definiti come risorse della pipeline. Se vengono definiti più artefatti, Azure Pipelines visualizza il primo artefatto elencato.

Cronologia della distribuzione per le fasi

Quando si distribuisce lo stesso servizio in più istanze, può essere difficile comprendere quale versione del sistema è attualmente distribuita in ogni istanza.

Con questo sprint si sta introducendo una nuova esperienza Fasi in Azure Pipelines che offre una chiara visibilità della distribuzione a livello di pipeline. La visualizzazione Fasi mostra l'esecuzione più recente della pipeline attualmente distribuita o nel processo di distribuzione in ogni fase della pipeline.

Si consideri, ad esempio, la pipeline YAML seguente con più fasi di distribuzione raggruppate per area:

stages:
- stage: deploy_WUS
  group: US Deployment
  displayName: Deploy to WUS
  jobs:
  - job:
    steps:
    - script: ./deploy.sh WUS
- stage: deploy_CUS
  group: US Deployment
  displayName: Deploy to CUS
  jobs:
  - job:
    steps:
    - script: ./deploy.sh CUS
- stage: deploy_WEU
  group: EU Deployment
  displayName: Deploy to WEU
  jobs:
  - job:
    steps:
    - script: ./deploy.sh WEU
- stage: deploy_CEU
  group: EU Deployment
  displayName: Deploy to CEU
  jobs:
  - job:
    steps:
    - script: ./deploy.sh CEU

Dopo aver eseguito la pipeline un paio di volte e si passa alla scheda Fasi , questo è ciò che viene visualizzato.

È possibile notare che l'esecuzione più recente che ha toccato la fase denominata Deploy to WUS è stata #20260317 che ha distribuito la versione di sistema 20260316.1. Per una fase, vengono visualizzate esecuzioni della pipeline riuscite o in corso che coinvolgono tale fase.

Se si fa clic sul nome della fase, ad esempio Deploy to WUS (Distribuisci in WUS), si accederà ai log della fase. Facendo clic su #20260317 • Distribuzione della versione 20260316.1, si accederà all'esecuzione di quella pipeline.

Se si fa clic sulla riga di una fase, si ottiene la relativa cronologia di distribuzione. La cronologia contiene esecuzioni completate e in corso che fanno riferimento alla fase.

Le pipeline di distribuzione possono avere centinaia di fasi organizzate in vari gruppi, ad esempio in una struttura circolare. Stiamo aggiungendo il supporto per specificare la fase di group. Nello screenshot precedente è possibile visualizzare due gruppi, Distribuzione stati Uniti e Distribuzione UE.

La group proprietà stage supporta più livelli di annidamento. Ovvero, è possibile avere un gruppo il cui nome legge EU Deployment\Italy, come nel caso seguente.

- stage: deploy_IT
  group: EU Deployment\Italy
  displayName: Deploy to Italy
  jobs:
  - job:
    steps:
    - script: echo ./deploy.sh IT

Quando si esegue questa fase, la visualizzazione Fasi viene aggiornata come nello screenshot seguente.

Le fasi vengono visualizzate finché è presente un'esecuzione che vi fa riferimento.

Una fase deve avere un nome per essere visualizzata nella scheda Fasi. Cioè, - stage: deploy_WUS apparirà mentre - stage: no.

Piani di test di Azure

Eseguire query e correlare elementi di lavoro tra progetti nei risultati dei test

Quando si analizzano i risultati dei test, potrebbe essere necessario cercare e correlare bug o altri elementi di lavoro che risiedono in un progetto diverso rispetto al risultato del test stesso. Ora è supportato questo scenario consentendo di eseguire query e correlare elementi di lavoro tra progetti. Per usare questa funzionalità, abilitare l'opzione Query tra progetti durante la ricerca di elementi di lavoro da un risultato del test case.

• Correlazione di bug tra progetti

• Correlazione di elementi di lavoro tra progetti

Passaggi successivi

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.

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