Miglioramenti alla copia del dashboard

Microsoft è lieta di annunciare alcuni miglioramenti attesi per l'anteprima di Copia dashboard. È ora possibile copiare un dashboard in un team diverso, nello stesso team o in un progetto diverso e la configurazione di team e query viene aggiornata nel nuovo dashboard. Ciò riduce ulteriormente al minimo il lavoro necessario per creare dashboard simili da zero per più team.

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

Generale

• Assegnare il ruolo di amministratore di Azure DevOps a un gruppo di Azure AD

Azure Pipelines

• Tentativi automatici per un'attività
• Utilizzare input da un'altra attività in un elemento Decorator
• Miglioramenti alla cronologia di utilizzo delle connessioni al servizio
• La specifica dell'agente predefinita per le pipeline classiche è ora Windows-2019

Reporting

• Miglioramenti del dashboard di copia
• Filtrare in base ai valori Null nel widget del grafico burn-down

Generale

Assegnare il ruolo di amministratore di Azure DevOps a un gruppo di Azure AD

Il ruolo di amministratore di Azure DevOps, necessario per configurare i criteri del tenant di Azure AD in Azure DevOps, può ora essere assegnato a un gruppo di Azure AD. Altre informazioni sull'uso dei gruppi di Azure AD per gestire le assegnazioni di ruolo in Azure AD.

Azure Pipelines

Tentativi automatici per un'attività

Quando si dispone di un'attività instabilità che ha esito negativo in modo intermittente in una pipeline, potrebbe essere necessario eseguire di nuovo la pipeline in modo che abbia esito positivo. Nella maggior parte dei casi, il modo migliore per risolvere un'attività o uno script non corretto consiste nel correggere l'attività o lo script stesso. Ad esempio, se l'attività di test non riesce in una pipeline a causa di test instabilità, è sempre consigliabile correggere i test instabilità e renderli più affidabili. Analogamente, se lo script non riesce una volta nel tempo, è preferibile correggere lo script, ad esempio introducendo nuovi tentativi all'interno dello script.

Esistono tuttavia alcuni casi in cui è consigliabile ripetere l'attività. Un caso d'uso comune è un'attività che scarica un pacchetto (ad esempio, NuGet, npm e così via). Si è spesso osservato che queste attività sono soggette a errori di rete e agli errori temporanei nei server di hosting del pacchetto. Sono stati ricevuti commenti e suggerimenti che sarebbe preferibile ripetere automaticamente tali attività non riuscite senza dover riavviare nuovamente l'intera pipeline.

In base ai commenti e suggerimenti, è stata aggiunta una funzionalità per ripetere automaticamente un'attività in una pipeline in caso di errore. Se si usano pipeline YAML, è possibile impostare questo input come segue:

- task: <name of task>
   retryCountOnTaskFailure: <max number of retries>
   ...

Quando si usano pipeline di compilazione o versione classiche, è possibile impostare questa proprietà nelle opzioni di controllo per l'attività.

Ecco alcuni aspetti da notare quando si usano tentativi:

• L'attività non riuscita viene ritentata immediatamente.
• Non esiste alcun presupposto sulla idempotenza dell'attività. Se l'attività ha effetti collaterali (ad esempio, se ha creato parzialmente una risorsa esterna), potrebbe non riuscire la seconda volta che viene eseguita.
• Non sono disponibili informazioni sul numero di tentativi resi disponibili per l'attività.
• Ai log attività viene aggiunto un avviso che indica che non è riuscito prima di riprovare.
• Tutti i tentativi di ripetizione di un'attività vengono visualizzati nell'interfaccia utente come parte dello stesso nodo attività.

Utilizzare input da un'altra attività in un elemento Decorator

Di recente è stata aggiunta una funzionalità per inserire automaticamente un'attività in una pipeline prima di un'altra attività di destinazione in tale pipeline. È ora in corso il miglioramento della funzionalità consentendo di personalizzare l'attività inserita usando i parametri di input dell'attività di destinazione. La sintassi per la scrittura di un elemento Decorator per eseguire questa operazione è la seguente:

{
    "contributions": [
        {
            "id": <my-required-task>,
            "type": "ms.azure-pipelines.pipeline-decorator",
            "targets": [
                "ms.azure-pipelines-agent-job.pre-task-tasks",
                "ms.azure-pipelines-agent-job.post-task-tasks"
            ],
            "properties": {
                "template": "my-decorator.yml",
                "targettask": <target-task-id>,
                "targettaskinputs": ["<name of input>"]
            }
        }
    ],
    ...
}

Questa funzionalità funziona solo quando si usa pre-task-tasks o post-task-tasks come destinazione per l'inserimento e si specifica nella targettask sezione delle proprietà del contributo. È quindi possibile aggiungere una proprietà aggiuntiva denominata targettaskinputs e specificare un elenco di nomi di parametri di input accettati dall'attività di destinazione. Questi input vengono ora resi disponibili per l'attività inserita.

Un caso d'uso comune che può essere eseguito da uno scenario di questo tipo è il seguente. Si supponga di voler inserire un'attività che porterà automaticamente il nome dell'artefatto pubblicato da una compilazione. Il nome dell'artefatto è un input per l'attività PublishBuildArtifacts . L'attività inserita può ora ottenere lo stesso parametro di input e usarlo per la registrazione.

Miglioramenti alla cronologia di utilizzo delle connessioni al servizio

Quando una pipeline usa una connessione al servizio, tale utilizzo viene registrato nella cronologia della connessione. Gli amministratori della connessione al servizio possono esaminare la cronologia di utilizzo passando alle impostazioni del progetto e selezionando la connessione al servizio appropriata. Si sono verificati alcuni problemi con la cronologia di utilizzo delle connessioni al servizio che sono state risolte con questo aggiornamento. Le correzioni includono quanto segue:

• Quando una connessione al servizio viene usata in un processo di distribuzione (invece di un normale processo), tale utilizzo non è stato registrato.
• Se sono state usate più connessioni al servizio in più fasi di una pipeline, tutte le connessioni al servizio mostrano un record nella cronologia di utilizzo anche se alcune fasi sono state ignorate.

La specifica dell'agente predefinita per le pipeline classiche è ora Windows-2019

Nelle note sull'ultima versione è stata annunciata una pianificazione deprecata per vs2017-win2016 le immagini ospitate. In preparazione a questo scopo, ora si modifica la specifica dell'agente predefinita durante la creazione di nuove pipeline nelle pipeline classiche in windows-2019.

Reporting

Miglioramenti del dashboard di copia

Microsoft è lieta di annunciare l'anteprima pubblica della fase 2 del dashboard di copia. Le query e la configurazione vengono ora eseguite con l'operazione di copia. Grazie per la vostra pazienza perché ci sono voluti un po 'di più del previsto per risolvere alcuni dei problemi.

L'anteprima è attivata per impostazione predefinita con il flag di funzionalità Copia esperienza dashboard (in funzionalità di anteprima).

Per copiare un dashboard, passare prima al dashboard da copiare. In secondo luogo, fare clic sul menu per visualizzare Copy Dashboard (Copia dashboard ) e quindi fare clic su di esso.

Specificare quindi il nome e la descrizione del nuovo dashboard e quindi selezionare il tipo di dashboard Team o Project. Quando si seleziona un dashboard del team, il nuovo progetto e il nuovo team vengono selezionati nelle rispettive caselle di riepilogo a discesa. Per un dashboard di Progetto, è necessario solo il progetto.

Si verrà visualizzati nel dashboard appena creato dopo aver fatto clic sul pulsante Crea . I widget e il layout rimangono invariati.

Dietro le quinte viene creata una cartella con il nome del nuovo dashboard in Query condivise. Tutte le query per il nuovo dashboard vengono copiate in tale cartella. I nomi delle query rimangono invariati. I widget con una configurazione team vengono aggiornati con il nuovo team. I widget con una configurazione team copiati da un dashboard del team in un dashboard di progetto mantengono la configurazione originale.

Filtrare in base ai valori Null nel widget del grafico burn-down

È ora possibile filtrare in base a un valore Null quando si usano Criteri campo nel widget del grafico burn-down. Questo comportamento è ora coerente con una query usando gli stessi criteri di campo.

Passaggi successivi

Passare ad Azure DevOps e dare un'occhiata.

Come fornire commenti e suggerimenti

Ci piacerebbe sentire cosa pensi di queste funzionalità. Usare il menu della Guida per segnalare un problema o fornire un suggerimento.

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

Grazie,

Aaron Hallberg