Condividi tramite

Definire, acquisire, valutare e gestire bug software in Azure Boards

  • Articolo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Come si tiene traccia e si gestiscono i difetti nel codice? Come assicurarsi che i problemi software e i commenti dei clienti vengano risolti rapidamente per supportare distribuzioni software di alta qualità? Come fai a fare progressi sulle nuove funzionalità e affrontare il tuo debito tecnico?

È necessario almeno un modo per acquisire i problemi software, classificarli in ordine di priorità, assegnarli a un membro del team e tenere traccia dello stato di avanzamento. Si vogliono gestire i difetti del codice in modi che si allineano alle procedure Agile.

Per supportare questi scenari, Azure Boards fornisce un tipo di elemento di lavoro specifico per tenere traccia dei difetti di codice denominati Bug. Gli elementi di lavoro di bug condividono tutte le funzionalità standard di altri tipi di elementi di lavoro con altri altri. Per una panoramica delle funzionalità standard, vedere Informazioni sugli elementi di lavoro e sui tipi di elemento di lavoro.

I bug forniscono anche le funzionalità seguenti:

  • Opzioni per ogni team per scegliere come tenere traccia dei bug
  • Strumenti di test per acquisire bug
  • Integrazione predefinita in Azure DevOps per tenere traccia dei bug collegati a compilazioni, versioni e test

Nota

I tipi di elementi di lavoro bug non sono disponibili con il processo Basic. Il processo Basic tiene traccia dei bug come Problemi ed è disponibile quando si crea un nuovo progetto da Azure DevOps Services o da Azure DevOps Server 2019.1 o versioni successive.

Prerequisiti

  • Accesso al progetto: da aggiungere a un progetto.

  • Autorizzazioni:

    • Impostare Visualizza elementi di lavoro in questo nodo e Modifica elementi di lavoro in questo nodo le autorizzazioni impostate su Consenti. Per impostazione predefinita, il gruppo Collaboratori dispone di queste autorizzazioni. Per altre informazioni, vedere Impostare le autorizzazioni di rilevamento del lavoro.

    • Per aggiungere nuovi tag agli elementi di lavoro, avere accesso di base o superiore e l'autorizzazione Crea nuova definizione tag a livello di progetto impostata su Consenti. Per impostazione predefinita, il gruppo Collaboratori dispone di questa autorizzazione.

      Nota

      Gli stakeholder non possono aggiungere nuovi tag, anche se l'autorizzazione è impostata in modo esplicito, a causa del livello di accesso. Per altre informazioni, vedere Informazioni di riferimento rapido sull'accesso di tipo Stakeholder.

  • Elementi di lavoro di posta elettronica: tutti i membri del progetto, inclusi quelli nel gruppo Lettori , possono inviare messaggi di posta elettronica contenenti elementi di lavoro.

Suggerimento

Per segnalare un bug, un utente deve avere almeno l'accesso degli stakeholder . Un utente deve disporre del set di autorizzazioni Modifica elementi di lavoro in questo nodo su Consenti per il percorso area in cui aggiunge il bug. Per altre informazioni, vedere Impostare le autorizzazioni di rilevamento del lavoro

Tipo di elemento di lavoro bug

L'immagine seguente mostra il tipo di elemento di lavoro Bug per il processo Scrum. Il tipo di elemento di lavoro Bug per i processi Agile e Capability Maturity Model Integration (CMMI) tiene traccia di informazioni simili. Viene visualizzato nel backlog del prodotto insieme ai requisiti o alla Schermata attività insieme alle attività.

Nota

Le immagini visualizzate dal portale Web potrebbero differire dalle immagini visualizzate in questo articolo. Queste differenze derivano dagli aggiornamenti apportati all'app Web, alle opzioni abilitate dall'utente o dall'amministratore e dal processo scelto durante la creazione del progetto: Agile, Basic, Scrum o CMMI. Il processo Basic è disponibile con Azure DevOps Server 2019 Update 1 e versioni successive.

Screenshot che mostra un modulo tipo di elemento di lavoro bug per il processo Scrum in Azure DevOps Server 2020 e nel servizio cloud.

Screenshot che mostra un modulo tipo di elemento di lavoro bug per il processo Scrum in Azure DevOps Server 2019.

Campi specifici dei bug

Il tipo di elemento di lavoro Bug usa alcuni campi specifici del bug. Per acquisire sia il problema iniziale che le individuazioni in corso, usare i campi descritti nella tabella seguente. Per informazioni sui campi specifici del bug definito per il processo CMMI (Capability Maturity Model Integration), vedere Bug, problemi e informazioni di riferimento sul campo rischi. Per informazioni su tutti gli altri campi, vedere Indice dei campi dell'elemento di lavoro.

Campo, gruppo o scheda

Utilizzo

Passaggi per riprodurre (nome descrittivo=Passaggi di riproduzione)

Usare per acquisire informazioni sufficienti in modo che altri membri del team possano comprendere completamente il difetto del codice. Includere le azioni eseguite per trovare o riprodurre il bug e il comportamento previsto.

Informazionidi sistema trovate nella compilazione

Informazioni sulla configurazione del software e del sistema rilevanti per il bug e i test da applicare. I campi Informazioni di sistema e Trovati in Compilazione vengono compilati automaticamente quando si crea un bug tramite uno strumento di test. Questi campi specificano informazioni sull'ambiente software e sulla compilazione in cui si è verificato il bug. Per altre informazioni, vedere Testare configurazioni diverse.

Criteri di accettazione

Specificare i criteri da soddisfare prima che il bug possa essere chiuso. Prima dell'inizio del lavoro, descrivere i criteri di accettazione del cliente il più chiaramente possibile. I team devono usare questi criteri come base per i test di accettazione e per valutare se un elemento è completato in modo soddisfacente.

Integrato nella compilazione

Specifica il nome della compilazione che incorpora il codice che corregge il bug. Questo campo deve essere specificato quando si risolve il bug.

Per Azure DevOps locale, per accedere a un menu a discesa di tutte le compilazioni eseguite, è possibile aggiornare le FIELD definizioni disponibili in Compilazione e integrazione in Compilazione per fare riferimento a un elenco globale. L'elenco globale viene aggiornato automaticamente con ogni compilazione eseguita. Per altre informazioni, vedere Eseguire query basate su campi di integrazione di compilazione e test.

Per informazioni su come definire i numeri di compilazione, vedere Configurazione delle pipeline classiche.

Priorità1

  • 1: il prodotto richiede una risoluzione corretta dell'elemento di lavoro prima che venga fornito e risolto presto.
  • 2: Il prodotto richiede una risoluzione corretta dell'elemento di lavoro prima della spedizione, ma non deve essere risolto immediatamente.
  • 3: La risoluzione dell'elemento di lavoro è facoltativa, in base a risorse, tempo e rischio.

Gravità1

Classificazione soggettiva dell'impatto di un bug o di un elemento di lavoro nel progetto o nel sistema software. Ad esempio: se un collegamento remoto all'interno dell'interfaccia utente (un evento raro) causa l'arresto anomalo di un'applicazione o di una pagina Web (un'esperienza cliente grave), è possibile specificare Gravità = 2 - Alta e Priorità = 3. I valori consentiti e le linee guida suggerite sono:

  • 1 - Critico: deve correggere. Un difetto che causa la chiusura di uno o più componenti di sistema o il sistema completo o causa un danneggiamento esteso dei dati. Non esistono metodi alternativi accettabili per ottenere i risultati richiesti.
  • 2 - Alto: prendere in considerazione la correzione. Un difetto che causa la chiusura di uno o più componenti di sistema o il sistema completo o causa un danneggiamento esteso dei dati. Esiste un metodo alternativo accettabile per ottenere i risultati necessari.
  • 3 - Medio: (Impostazione predefinita) Un difetto che fa sì che il sistema produca risultati non corretti, incompleti o incoerenti.
  • 4 - Basso: difetto secondario o cosmetico che presenta soluzioni alternative accettabili per ottenere i risultati richiesti.

Distribuzione

Il controllo Distribuzione supporta collegamenti a e visualizzazione di versioni che contengono elementi di lavoro. Per usare il controllo, è necessario abilitare le impostazioni per la versione. Per altre informazioni, vedere Collegare elementi di lavoro alle versioni più avanti in questo articolo.

Sviluppo

Il controllo Sviluppo supporta i collegamenti a e la visualizzazione di collegamenti creati agli oggetti di sviluppo. Questi oggetti includono i commit Git e le richieste pull o i set di modifiche TFVC e gli elementi con controllo delle versioni. È possibile definire collegamenti dall'elemento di lavoro o dai commit, dalle richieste pull o da altri oggetti di sviluppo. Per altre informazioni, vedere Collegare elementi di lavoro allo sviluppo più avanti in questo articolo.

Note

1 Per modificare la selezione o l'elenco a discesa del menu, vedi Personalizzare l'esperienza di rilevamento del lavoro. Il metodo di personalizzazione dipende dal modello di processo usato dal progetto.

Scegliere il modo in cui il team tiene traccia dei bug

Il team può tenere traccia dei bug come requisiti o come attività. Per supportare la scelta del team, considerare i fattori seguenti.

  • Dimensioni del team. I team più piccoli possono mantenere un footprint leggero monitorando i bug come requisiti.
  • Requisiti dell'organizzazione per tenere traccia del lavoro. Se il team è necessario per tenere traccia delle ore, scegliere di tenere traccia dei bug come attività.
  • Organizzazione del lavoro del team. Se il team si basa sul backlog del prodotto per classificare in ordine di priorità il lavoro e aggiungere bug, tenere traccia dei bug come requisiti.
  • Gli strumenti che il team vuole usare, ad esempio il riquadro Pianificazione, il grafico velocità, le previsioni, il rollup e i piani di recapito. Tenere traccia dei bug come attività impedisce l'uso di diversi di questi strumenti.

La tabella seguente riepiloga le tre opzioni che i team devono tenere traccia dei bug. Per altre informazioni e per impostare l'opzione per il team, vedere Visualizzare i bug nei backlog e nelle bacheche.

Opzione

Scegli quando vuoi...

Tenere traccia dei bug come requisiti

Nota

  • I bug vengono assegnati alla categoria Requisiti

Tenere traccia dei bug come attività

  • Stimare il lavoro per bug simili alle attività
  • Aggiornare lo stato del bug nei taskboard sprint
  • Collegare bug ai requisiti come elementi figlio
  • Trascinare i bug nel riquadro Pianificazione per assegnare bug a uno sprint

Nota

  • I bug vengono assegnati alla categoria attività
  • Storie utente (Agile), Elementi backlog prodotto (Scrum) o Requisiti (CMMI) sono il tipo di elemento di lavoro padre naturale per Bug
  • I bug non sono visibili nei piani di recapito

I bug non vengono visualizzati nei backlog o nelle bacheche

  • Gestire i bug usando query

Nota

  • I bug sono associati alla categoria Bug e non vengono visualizzati nei backlog o nelle bacheche
  • I bug non sono visibili nei backlog, nelle bacheche, nei backlog sprint, nelle lavagne o nei piani di recapito
  • Non è possibile trascinare i bug nel riquadro Pianificazione per assegnare bug a uno sprint

Personalizzare il tipo di elemento di lavoro

È possibile personalizzare i tipi di bug e altri elementi di lavoro. In alternativa, creare tipi personalizzati per tenere traccia dei problemi software o dei commenti dei clienti. Per tutti i tipi di elemento di lavoro, è possibile personalizzare gli elementi seguenti:

  • Aggiungere o rimuovere campi personalizzati
  • Aggiungere controlli personalizzati o schede personalizzate all'interno del modulo dell'elemento di lavoro
  • Personalizzare gli stati del flusso di lavoro
  • Aggiungere regole condizionali
  • Scegliere il livello di backlog in cui vengono visualizzati gli elementi di lavoro

Prima di personalizzare il processo, è consigliabile consultare Informazioni sulla configurazione e la personalizzazione di Azure Boards.

Per personalizzare il processo specifico, vedere Personalizzare un processo di ereditarietà.

Per personalizzare il processo specifico, vedere Personalizzare un processo di ereditarietà o Personalizzare il modello di processo XML locale.

Aggiungere o acquisire bug

È possibile definire bug da diversi strumenti di Azure DevOps. Questi strumenti includono backlog e schede e strumenti di test.

Suggerimento

Per impostazione predefinita, il campo Titolo è l'unico campo obbligatorio quando si crea un bug. È possibile aggiungere bug nello stesso modo in cui si aggiungono storie utente o elementi di backlog del prodotto usando Azure Boards. È possibile apportare alcuni campi necessari aggiungendo regole condizionali in base a una modifica dello stato. Per altre informazioni, vedere Aggiungere una regola a un tipo di elemento di lavoro.

Aggiungere un bug dal backlog o dalla scheda

Se il team ha scelto di gestire i bug con i requisiti, è possibile definire bug dal backlog o dalla lavagna del prodotto. Per altre informazioni, vedere Creare il backlog del prodotto o Usare la scheda.

  • Aggiungere un bug dal backlog del prodotto

    Screenshot che mostra l'aggiunta di un bug dal backlog del prodotto.

  • Aggiungere un bug dalla scheda

    Screenshot che mostra l'aggiunta di un bug dalla scheda.

Suggerimento

Quando si aggiunge un bug dal backlog o dalla scheda del prodotto, al bug viene assegnato automaticamente il percorso area predefinito e il percorso di iterazione definiti per il team. Per altre informazioni, vedere Impostazioni predefinite del team a cui fanno riferimento backlog e bacheche.

Aggiungere un bug dal backlog sprint o dalla schermata attività

Se il team ha scelto di gestire i bug con le attività, è possibile definire bug dalla scheda, dal backlog del prodotto, dal backlog sprint o dallo Sprint Taskboard. Si aggiunge un bug come figlio a un elemento di lavoro del backlog del prodotto.

Creare un bug da uno strumento di test

I due strumenti di test che è possibile usare per aggiungere bug durante i test includono il portale Web Test Runner e l'estensione Test & Feedback.

  • Test Runner: quando si eseguono test manuali, è possibile scegliere Crea bug. Per altre informazioni, vedere Eseguire test manuali.

    Screenshot che mostra Test Runner, in cui è possibile aggiungere un bug.

  • Estensione Test & Feedback: quando si eseguono test esplorativi, è possibile scegliere Crea bug o Crea attività. Per altre informazioni, vedere Test esplorativi con l'estensione Test & Feedback.

    Screenshot che mostra l'estensione Test & Feedback, in cui è possibile aggiungere una funzionalità di bug o attività.

Ciclo di vita dei bug e stati del flusso di lavoro

Come per tutti gli altri tipi di elemento di lavoro, il tipo di elemento di lavoro Bug ha un flusso di lavoro ben definito. Ogni flusso di lavoro è costituito da tre o più stati e da un motivo. I motivi specificano il motivo per cui l'elemento è passato da uno stato a un altro. Le immagini seguenti illustrano il flusso di lavoro di bug predefinito definito per i processi Agile, Scrum e CMMI .

Agile Scrum CMMI
Diagramma che mostra gli stati del flusso di lavoro di bug nel modello di processo Agile. Il diagramma mostra gli stati del flusso di lavoro dei bug nel modello di processo Scrum. Il diagramma mostra gli stati del flusso di lavoro dei bug nel modello di processo CMMI.

Per i bug scrum, si modifica lo stato da Commit (simile ad Attivo) a Fine. Per Agile e CMMI, risolvere prima di tutto il bug e selezionare un motivo che indica che il bug è stato corretto. In genere, la persona che ha creato il bug verifica la correzione e aggiorna lo stato da Risolto a Chiuso. Se si trova più lavoro dopo aver risolto o chiuso un bug, riattivarlo impostando Stato su Commit o Attivo.

Nota

Il tipo di elemento di lavoro del bug del processo Agile in precedenza aveva una regola che riassegnava il bug alla persona che l'ha creata. Questa regola è stata rimossa dal processo di sistema predefinito. È possibile ripristinare questa automazione aggiungendo una regola. Per un processo di ereditarietà, vedere Automatizzare la riassegnazione in base alla modifica dello stato.

Verificare una correzione

Per verificare una correzione, uno sviluppatore o un tester tenta di riprodurre il bug e cercare un comportamento più imprevisto. Se necessario, devono riattivare il bug.

Quando si verifica una correzione di bug, è possibile che il bug non sia stato corretto o che si potrebbe non essere d'accordo con la risoluzione. In questo caso, discutere il bug con la persona che l'ha risolta, venire a un accordo e possibilmente riattivare il bug. Se si riattiva un bug, includere i motivi per riattivare il bug nella descrizione del bug.

Chiudere un bug

Si chiude un bug quando un membro del team lo verifica come corretto. Tuttavia, è anche possibile chiudere un bug per uno dei motivi seguenti. I motivi disponibili dipendono dal processo di progetto e dagli stati di transizione dei bug.

Processo Agile:

  • Differito: rinviare la correzione di bug fino alla versione successiva del prodotto.
  • Correzione: il bug viene verificato come corretto.
  • Duplicato: bug tiene traccia di un altro bug attualmente definito. È possibile collegare ogni bug con il tipo di collegamento Duplicato/Duplicato e chiudere uno dei bug.
  • Come progettato: la funzionalità funziona come progettato.
  • Non è possibile riprodurre: i test dimostrano che il bug non può essere riprodotto.
  • Obsoleto: la funzionalità del bug non è più presente nel prodotto.
  • Copiato nel backlog: è stata aperta una storia utente per tenere traccia del bug.

Processo scrum:

  • Non è un bug: il bug viene verificato che non è un bug.
  • Duplicato: bug tiene traccia di un altro bug attualmente definito. È possibile collegare ogni bug con il tipo di collegamento Duplicato/Duplicato e chiudere uno dei bug.
  • Rimosso dal backlog: bug verificato che non è un bug. Rimuovere il bug dal backlog.
  • Lavoro completato: il bug è stato verificato come corretto.

Processo CMMI:

  • Differito: rinviare la correzione di bug fino alla versione successiva del prodotto.
  • Duplicato: bug tiene traccia di un altro bug attualmente definito. È possibile collegare ogni bug con il tipo di collegamento Duplicato/Duplicato e chiudere uno dei bug.
  • Rifiutato: il bug viene verificato che non è un bug.
  • Verificato: il bug viene verificato come corretto.

Suggerimento

Dopo la chiusura di un bug e la correzione viene rilasciata attivamente nelle distribuzioni, è consigliabile non riaprirla mai a causa della regressione. È invece consigliabile aprire un nuovo bug e collegarsi al bug chiuso meno recente.

È sempre consigliabile descrivere altri dettagli per la chiusura di un bug nel campo Discussione per evitare confusione futura sul motivo per cui il bug è stato chiuso.

Automatizzare la chiusura di bug durante l'unione di richieste pull

Se il team usa un repository Git, è possibile impostare Lo stato in bug collegati e altri elementi di lavoro per chiudere al termine dell'unione delle richieste pull. Per altre informazioni, vedere Impostare lo stato dell'elemento di lavoro nella richiesta pull più avanti in questo articolo.

Elencare e valutare i bug

La maggior parte dei team, qualunque opzione abbia scelto di tenere traccia dei bug, definire una o più query di bug. Con le query è possibile elencare bug attivi, bug non assegnati, bug non aggiornati, tendenze di bug e altro ancora. È possibile aggiungere query e grafici di query ai dashboard del team per monitorare lo stato dei bug e lo stato di avanzamento.

Query di bug

Aprire una query condivisa o usare l'editor di query per creare query di bug utili, ad esempio le opzioni seguenti:

  • Bug attivi per priorità (State <> Done o State <> Closed)
  • Bug in corso (State = Committed o State = Active)
  • Bug da correggere per una versione di destinazione (Tags Contains RTM)
  • Bug recenti, ad esempio bug aperti nelle ultime tre settimane (Created Date > @Today-21)

Quando si hanno le query di interesse per il team, è possibile creare grafici di stato o di tendenza. È anche possibile aggiungere il grafico creato a un dashboard.

Modalità di valutazione nei risultati della query

Dopo aver iniziato a scrivere codice e testare, tenere riunioni periodiche di valutazione per esaminare e classificare i bug. In genere, il proprietario del progetto esegue le riunioni di valutazione dei bug. I responsabili del team, gli analisti aziendali e altri stakeholder che possono parlare di rischi specifici del progetto partecipano alle riunioni di valutazione.

Il proprietario del progetto può definire una query condivisa per individuare bug nuovi e riaperti per elencare i bug da valutare.

Dalla pagina dei risultati della query è possibile spostarsi verso l'alto e verso il basso all'interno dell'elenco di elementi di lavoro di bug usando le frecce su e giù. Quando si esamina ogni bug, è possibile assegnarlo, aggiungere dettagli o impostare la priorità.

Screenshot del riquadro Risultati query, Bug attivi e Modalità di valutazione a destra.

Organizzare e assegnare bug a uno sprint

Se il team tiene traccia dei bug come requisiti, visualizzare l'elenco dei bug attivi dal backlog. Con la funzione di filtro, è possibile concentrarsi esclusivamente sui bug. Dal backlog del prodotto è anche possibile eseguire le attività seguenti:

Se il team tiene traccia dei bug come attività, usare le query gestite per elencare e valutare i bug. In ogni sprint vengono visualizzati i bug assegnati allo sprint dal backlog sprint o taskboard.

Elementi del pannello delle attività e voci dell'elenco di query

È possibile notare e chiedersi perché gli elementi visualizzati in uno sprint Taskboard possono differire da un elenco di query creato in un backlog sprint corrispondente.

È possibile assegnare attività o bug a un'iterazione, ma non collegarli a un elemento backlog padre. Questi elementi vengono visualizzati nella query creata, ma potrebbero non essere visualizzati nella lavagna stessa. Il sistema esegue la query e quindi applica alcuni processi in background prima di visualizzare gli elementi taskboard.

Questi motivi possono causare la mancata visualizzazione di elementi di lavoro appartenenti alla categoria attività in un backlog sprint o in Taskboard:

  • L'attività o il bug non è collegato a un elemento backlog padre. Solo i bug e le attività sono collegati a un elemento backlog del prodotto padre (Scrum), alla storia utente (Agile) o al requisito (CMMI) con un percorso di iterazione impostato sullo sprint visualizzato nella pagina backlog dello sprint.
  • L'attività o il bug è un elemento padre di un'altra attività o bug oppure la storia utente è un elemento padre di un'altra storia utente. Se si crea una gerarchia di attività, bug o storie utente, vengono visualizzate solo le attività a livello figlio o le storie a livello figlio nella parte inferiore della gerarchia. Per altre informazioni, vedere Risolvere i problemi di riordinamento e annidamento.
  • L'elemento padre collegato dell'attività o del bug corrisponde a un elemento backlog definito per un altro team. In alternativa, il percorso dell'area dell'elemento di backlog padre dell'attività o del bug differisce dal percorso dell'area dell'attività o del bug.

Creare test inline collegati a bug

Quando il team tiene traccia dei bug come requisiti, è possibile usare la bacheca per aggiungere test per verificare le correzioni di bug.

Screenshot della scheda, tre colonne che mostrano test inline aggiunti e collegati a bug.

Aggiornare lo stato del bug

È possibile aggiornare lo stato del bug trascinando e rilasciando bug in una nuova colonna in una scheda.

Personalizzare la scheda per tenere traccia degli stati intermedi

È possibile aggiungere colonne intermedie per tenere traccia dello stato del bug nella scheda. È anche possibile definire query che filtrano in base allo stato di una colonna scheda. Per altre informazioni, vedere gli articoli seguenti:

Automatizzare la riassegnazione dei bug in base allo stato del flusso di lavoro

Per automatizzare le azioni di selezione, aggiungere regole personalizzate al tipo di elemento di lavoro Bug. Ad esempio, aggiungere una regola come illustrato nell'immagine seguente. Questa regola specifica di riassegnare un bug alla persona che ha aperto il bug quando un membro del team lo risolve. In genere, la persona verifica che il bug sia stato corretto e chiuda il bug. Per altre informazioni, vedere Applicare regole agli stati del flusso di lavoro (processo di ereditarietà).

Screenshot della regola definita per riassegnare il bug in base allo stato risolto.

Impostare lo stato dell'elemento di lavoro nella richiesta pull

Quando si crea una richiesta pull, è possibile impostare il valore di stato degli elementi di lavoro collegati nella descrizione. Seguire la sintassi: {state value}: #ID.

Quando si unisce la richiesta pull, il sistema legge la descrizione e aggiorna lo stato dell'elemento di lavoro. L'esempio seguente imposta gli elementi di lavoro #300 e #301 su Resolved e #323 e #324 su Closed.

Screenshot dell'impostazione dello stato dell'elemento di lavoro all'interno di una richiesta pull.

Nota

Questa funzionalità richiede l'installazione dell'aggiornamento di Azure DevOps Server 2020.1. Per altre informazioni, vedere Note sulla versione di Azure DevOps Server 2020 Update 1 RC1, Boards.

Integrazione in Azure DevOps

Uno dei metodi usati da Azure DevOps per supportare l'integrazione consiste nel collegare oggetti ad altri oggetti. Oltre a collegare elementi di lavoro agli elementi di lavoro, è anche possibile collegare elementi di lavoro ad altri oggetti. Collegamento a oggetti quali compilazioni, versioni, rami, commit e richieste pull, come illustrato nell'immagine seguente.

Diagramma che mostra i tipi di collegamento usati per collegare elementi di lavoro a oggetti di compilazione e rilascio.

È possibile aggiungere un collegamento dall'elemento di lavoro o dagli oggetti di compilazione e rilascio.

Il controllo Sviluppo supporta il collegamento e la visualizzazione di collegamenti eseguiti a compilazioni, commit Git e richieste pull. Quando viene usato un repository TFVC, supporta i collegamenti ai set di modifiche e agli elementi con controllo delle versioni. Se si sceglie il collegamento, viene aperto l'elemento corrispondente in una nuova scheda del browser. Per altre informazioni, vedere Gestire lo sviluppo Git da un elemento di lavoro.

Screenshot che mostra il controllo di sviluppo nel modulo dell'elemento di lavoro con collegamenti di esempio per la compilazione, le richieste pull e i commit.

Il controllo Distribuzione supporta collegamenti a e visualizzazione di versioni che contengono gli elementi di lavoro. Ad esempio, l'immagine seguente mostra diverse versioni contenenti collegamenti all'elemento di lavoro corrente. È possibile espandere ogni versione per visualizzare i dettagli su ogni fase. È possibile scegliere il collegamento per ogni versione e fase per aprire la versione o la fase corrispondente. Per altre informazioni, vedere Collegare elementi di lavoro alle distribuzioni.

Screenshot che mostra il controllo distribuzione nel modulo dell'elemento di lavoro con le versioni di esempio.

Le pipeline vengono spesso definite per l'esecuzione automatica quando si verifica un nuovo commit in un repository Git. Gli elementi di lavoro associati alle pipeline di commit vengono visualizzati come parte dell'esecuzione della pipeline se si personalizzano le impostazioni della pipeline. Per altre informazioni, vedere Personalizzare la pipeline.

Screenshot delle impostazioni della pipeline con collegare automaticamente gli elementi di lavoro in questa esecuzione dal ramo selezionato evidenziato.

Creare o modificare un elemento di lavoro in caso di errore di compilazione

Se si usano pipeline classiche (non YAML), è possibile creare elementi di lavoro in caso di errore di compilazione. Per altre informazioni, vedere Creare un elemento di lavoro in caso di errore.

È possibile tenere traccia dello stato, delle assegnazioni e delle tendenze dei bug usando query che è possibile creare grafici e aggiungere a un dashboard. Ad esempio, di seguito sono riportati due esempi che mostrano le tendenze di bug attive in base allo stato e ai bug attivi per priorità nel tempo.

Screenshot di due grafici di query di bug attivi, Tendenze bug per stato e priorità.

Per altre informazioni su query, grafici e dashboard, vedere query gestite, grafici e dashboard.

Usare le visualizzazioni di Analisi e il servizio Analisi per creare report sui bug

Il servizio Analytics è la piattaforma di creazione di report per Azure DevOps. Sostituisce la piattaforma precedente basata su SQL Server Reporting Services.

Le viste di analisi forniscono filtri predefiniti per visualizzare gli elementi di lavoro. Per la segnalazione di bug sono supportate quattro visualizzazioni analitiche. È possibile usare queste visualizzazioni come definite o modificarle ulteriormente per creare una visualizzazione personalizzata filtrata.

  • Bug - Tutta la cronologia per mese
  • Bug - Ultime 26 settimane
  • Bug - Ultimi 30 giorni
  • Bug - Oggi

Per altre informazioni sull'uso delle visualizzazioni analitiche, vedere Informazioni sulle visualizzazioni di Analisi e Creare un report sui bug attivi in Power BI in base a una visualizzazione analisi personalizzata.

È possibile usare Power BI per creare report più complessi rispetto a una query. Per altre informazioni, vedere Connettersi con Power BI Data Connector.

Report di bug predefiniti di SQL Server

I report seguenti sono supportati per i processi Agile e CMMI.

Questi report richiedono che SQL Server Analysis Services e SQL Server Reporting Services siano configurati per il progetto. Per informazioni su come aggiungere report di SQL Server per un progetto, vedere Aggiungere report a un progetto.

Estensioni del Marketplace

Sono disponibili più estensioni del Marketplace correlate ai bug. Vedere Marketplace per Azure DevOps.

Per altre informazioni sulle estensioni, vedere Estensioni di Azure Boards sviluppate da Microsoft.

Passaggi successivi

Usare i modelli per aggiungere e aggiornare gli elementi di lavoro

Backlog e scheda del prodotto

Bacheca

Backlog sprint e Taskboard

Integrazione in Azure DevOps

Risorse del settore