Disponibilità generale dei piani di consegna 2.0

Siamo molto lieti di annunciare che i piani di recapito 2.0 sono disponibili a livello generale! I piani di recapito 2.0 offrono 3 scenari chiave: una visualizzazione della sequenza temporale del piano, lo stato di avanzamento del lavoro e il rilevamento delle dipendenze.

Per informazioni dettagliate, vedere le descrizioni delle funzionalità seguenti.

Azure Boards (Pannelli di Azure)

• I piani di recapito 2.0 sono disponibili a livello generale
• Nuova API REST per la capacità di iterazione
• La Copia Dashboard è disponibile ora in anteprima pubblica

Azure Pipelines

• Modifica dei criteri di preinstallazione di .NET SDK negli agenti Ubuntu ospitati da Microsoft
• Autorizzazioni e controlli sui gruppi di variabili e sui file sicuri
• Anteprima del supporto dei modelli nell'editor YAML
• Ubuntu-16.04 verrà rimosso dai pool ospitati da Microsoft nel mese di settembre 2021

Azure Boards (Pannelli di Azure)

I Delivery Plans 2.0 sono generalmente disponibili.

Siamo lieti di annunciare che Delivery Plans 2.0 è disponibile per tutti! Offre 3 scenari chiave:

• Visualizzazione della sequenza temporale del piano
• Avanzamento del lavoro
• Rilevamento delle dipendenze

Questi scenari funzionano tra team e progetti. I piani di recapito 2.0 sono ora nativi del prodotto, quindi un'estensione non è più necessaria. I piani creati con l'estensione originale Plans continueranno a funzionare in Delivery Plans.

Ecco un confronto rapido delle differenze tra i Piani e i Piani di recapito

Funzionalità dei piani di recapito

Di seguito sono riportate le funzionalità principali. Anche i filtri, i marcatori e i criteri di campo fanno parte dei piani di recapito.

Ci sono due viste principali: condensato ed espanso

I piani di recapito 2.0 consentono di visualizzare tutti gli elementi di lavoro del piano in una sequenza temporale, usando le date di inizio e di destinazione o le date di iterazione. L'ordine di precedenza è le date di inizio e di destinazione, seguite dall'iterazione. In questo modo è possibile aggiungere elementi di lavoro a livello di portfolio come Epic che spesso non sono definiti a un'iterazione.

Ci sono due viste principali la vista condensata e la visualizzazione espansa. È anche possibile ingrandire e ridurre il piano facendo clic sulla lente di ingrandimento sul lato destro del piano.

• Vista condensata

  La visualizzazione ridotta mostra tutte le schede degli elementi di lavoro compresse , ovvero non vengono visualizzate tutte le informazioni sulla scheda. Questa vista è utile per una visione complessiva del lavoro nel piano. Per comprimere i campi della scheda, fare clic sull'icona della scheda accanto alle icone di ingrandimento sul lato destro del piano.

  Ecco un esempio di un piano che alterna tra le visualizzazioni condensate ed espanse.

  

• Visualizzazione espansa

  La visualizzazione espansa mostra lo stato di avanzamento di un elemento di lavoro conteggiando il numero di elementi figlio e collegati e mostrando la percentuale di completamento. Attualmente lo stato di avanzamento è determinato dal conteggio degli elementi di lavoro.

  Di seguito è riportato un esempio di piano che usa una visualizzazione espansa. Si notino le barre di avanzamento e la percentuale di completamento.

  

Rilevamento delle dipendenze

Il monitoraggio delle dipendenze si basa sui collegamenti predecessore e successore definiti negli elementi di lavoro. Se tali collegamenti non sono definiti, non verranno visualizzate righe di dipendenza. Quando si verifica un problema di dipendenza con un elemento di lavoro, l'icona del collegamento alle dipendenze è colorata di rosso.

• Visualizzazione delle dipendenze

  Le dipendenze specifiche vengono visualizzate tramite il pannello delle dipendenze che mostra tutte le dipendenze per l'elemento di lavoro, inclusa la direzione. Un punto esclamativo rosso indica un problema di dipendenza. Per visualizzare il pannello, è sufficiente fare clic sull'icona del collegamento di dipendenza nell'angolo in alto a destra della scheda. Ecco alcuni esempi di dipendenze.

  

  

• Righe di dipendenza

  Le dipendenze tra gli elementi di lavoro vengono visualizzate con linee di direzione direzionali tra i rispettivi elementi di lavoro. Dipendenze multiple verranno visualizzate come linee multiple. Una linea colorata rossa indica un problema.

  Ecco alcuni esempi.

  

  Di seguito è riportato un esempio di elemento di lavoro con più dipendenze e funziona anche usando la visualizzazione ridotta.

  

  Quando si verifica un problema, il colore della linea è rosso e quindi l'icona della dipendenza.

  Ecco un esempio.

  

Applicazione di stili alle schede

Le schede possono ora essere stilite usando regole, ad esempio le schede Kanban. Aprire le impostazioni del piano e fare clic su Stili. Nel riquadro Stili fare clic su + Aggiungi regola di stile per aggiungere la regola e quindi fare clic su Salva. Possono essere presenti fino a 10 regole e ogni regola può avere fino a 5 clausole.

• Prima di

• Dopo

La Dashboard è ora disponibile in anteprima pubblica

Con questa versione, un dashboard del team o del progetto può ora essere copiato nello stesso progetto o in un nuovo progetto. I widget e il layout del dashboard verranno copiati, ma i widget dovranno comunque essere configurati con nuove query e impostazioni.

Per visualizzare in anteprima questa funzionalità, è sufficiente attivare la funzione denominata Esperienza del dashboard di copia (nelle funzionalità di anteprima).

Ecco i passaggi per copiare un dashboard:

1. Vai al dashboard che vuoi copiare. Da qui fare clic sul menu per aprire Copia Dashboard e quindi fare clic su di esso.

2. Immettere il nome e la descrizione del nuovo dashboard, quindi selezionare il tipo di dashboard, Team o Project. Quando si seleziona un Team Dashboard, il nuovo progetto e il nuovo team vengono selezionati rispettivamente nelle caselle a discesa del progetto e del team. Per una dashboard del progetto, è richiesto solo il progetto.

Nuova API REST per la capacità di iterazione

È ora possibile ottenere la capacità totale per tutti i team in un'iterazione usando la nuova API REST Iterationcapacities . Fornisci il iterationId e l'API restituirà la capacità totale per ogni team associato all'iterazione, oltre a un totale complessivo. Questa funzionalità renderà più semplice la pianificazione della capacità per un incremento. Per ulteriori informazioni sulle capacità di iterazione, vedere la documentazione qui.

Azure Pipelines

Modifica dei criteri di preinstallazione di .NET SDK negli agenti Ubuntu ospitati da Microsoft

Stiamo modificando le versioni di .NET SDK preinstallate negli agenti Ubuntu ospitati da Microsoft. Attualmente, vengono installate tutte le versioni disponibili e supportate di .NET SDK (2.1.x, 3.1.x, 5.0.x). Questo approccio verrà modificato a favore dell'installazione della versione patch più recente per ogni versione delle funzionalità. Questa modifica viene apportata per fornire più spazio libero e per le nuove richieste di strumenti.

Significato

La versione dell'SDK è costituita dalle parti seguenti: x.y.znn. z è la versione della funzionalità ed nn è la versione patch. Ad esempio, per la versione 2.1.302, la versione della funzionalità è 3 e 02 è la versione patch. In base al nuovo approccio, verrà installata solo la versione patch più recente per ogni versione delle funzionalità, ad esempio solo 2.1.302 verrà installata per la versione 2.1.3x, solo 2.1.403 per 2.1.4x e così via. Tutte le versioni di .NET SDK che non sono le versioni più recenti delle patch verranno rimosse dalle immagini Ubuntu il 14 giugno. Questa modifica influisce su tutte le versioni di Ubuntu negli agenti ospitati da Microsoft.

Data di destinazione

La distribuzione delle immagini aggiornate inizierà il 14 giugno e richiederà 3-4 giorni.

Possibile impatto

Se si utilizza un file global.json, la compilazione sarà influenzata nei seguenti casi:

La compilazione avrà esito negativo, se il file global.json contiene la proprietà e la rollForward: disable versione dell'SDK che non è la versione più recente della patch. Per esempio:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "disable"
  }
}

La versione di .NET SDK verrà modificata automaticamente alla patch più recente se il file global.json contiene la rollForward: patch proprietà . Per esempio:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "patch"
  }
}

Se il rollForward campo non è specificato nel file global.json, non verrà apportata alcuna modifica. Viene usato il livello di patch installato più recente.

Se è necessario usare la versione esatta di .NET SDK che non è la patch più recente, usare l'attivitàUseDotNet per installarla come parte della compilazione:

steps:
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk'
  inputs:
    version: <dotnet version>

Autorizzazioni e controlli sui gruppi di variabili e sui file sicuri

È possibile usare diversi tipi di risorse condivise nelle pipeline YAML. Ad esempio, le connessioni al servizio, i gruppi di variabili, i file protetti, i pool di agenti, gli ambienti o i repository. Per proteggere una pipeline dall'accesso a una risorsa, il proprietario della risorsa può configurare le autorizzazioni e controllare tale risorsa. Ogni volta che una pipeline tenta di accedere alla risorsa, vengono valutate tutte le autorizzazioni e i controlli configurati. Queste protezioni sono disponibili da un po' di tempo su connessioni del servizio, ambienti e pool di agenti. Sono stati aggiunti di recente ai repository. Con questa versione, verranno aggiunte le stesse protezioni ai gruppi di variabili e ai file protetti.

Per limitare l'accesso a un gruppo di variabili o a un file sicuro a un piccolo set di pipeline, usare la funzionalità delle Autorizzazioni Pipeline .

Per configurare controlli o approvazioni che devono essere valutati ogni volta che viene eseguita una pipeline, usare la funzionalità Approvazioni e controlli per Libreria.

Anteprima del supporto dei modelli nell'editor YAML

I modelli sono una funzionalità comunemente usata nelle pipeline YAML. Sono un modo semplice per condividere frammenti di codice pipeline. Sono anche un meccanismo potente per verificare o applicare sicurezza e governance tramite la pipeline.

Azure Pipelines supporta un editor YAML utile per la modifica della pipeline. In precedenza, l'editor non supportava i modelli. Gli autori di pipeline YAML non sono riusciti a ottenere assistenza IntelliSense quando si usa un modello. Con questa versione viene visualizzato in anteprima il supporto per i modelli nell'editor YAML. Per abilitare questa anteprima, passare alle funzionalità di anteprima nell'organizzazione di Azure DevOps e abilitare l'editor di modelli YAML.

Quando si modifica il file YAML di Azure Pipelines principale, è possibile includere o estendere un modello. Quando si digita il nome del modello, verrà richiesto di convalidare il modello. Dopo la convalida, l'editor YAML riconosce lo schema del modello, inclusi i parametri di input.

Dopo la convalida, è possibile scegliere di passare al modello. Sarà possibile apportare modifiche al modello usando tutte le funzionalità dell'editor YAML.

Si noti che questa funzionalità è in anteprima. Esistono limitazioni note, alcune delle quali stiamo lavorando per risolvere. Se il modello ha parametri obbligatori che non vengono forniti come input nel file YAML principale, la convalida non riesce e richiede di fornire tali input. In un'esperienza ideale, la convalida non deve essere bloccata e dovrebbe essere possibile compilare i parametri di input usando intellisense. Inoltre, non è possibile creare un nuovo modello dall'editor. È possibile usare o modificare solo i modelli esistenti.

Ubuntu-16.04 verrà rimosso dai pool ospitati da Microsoft nel mese di settembre 2021

Il supporto tradizionale di 5 anni di Ubuntu 16.04 da Canonical termina ad aprile 2021. Per mantenere aggiornato e protetto l'ambiente, rimuoveremo Ubuntu 16.04 il 20 settembre 2021.

Sarà necessario eseguire la migrazione dei flussi di lavoro ubuntu-16.04 a ubuntu-18.04 o ubuntu-latest che verrà eseguito in Ubuntu 20.04 LTS.

Per assicurarsi che tutti siano a conoscenza di questa modifica, sono stati pianificati due brevi interruzioni di erogazione di corrente. Tutte le build ubuntu 16.04 avranno esito negativo durante il periodo di brownout. È quindi consigliabile eseguire la migrazione delle pipeline prima del 6 settembre 2021.

I brownout sono programmati provvisoriamente per le date e le ore seguenti. Questi tempi verranno aggiornati man mano che ci avviciniamo a questo periodo.

6 settembre 2021 05:00 UTC - 10:00 UTC

14 settembre 2021 05:00 UTC - 10:00 UTC

Passaggi successivi

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.

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

Grazie,

Aaron Hallberg