Come posso integrare il mio sistema di integrazione continua con il mio sistema di tracciamento dei bug?

Question

Utilizzo cruisecontrol.rb per CI e FogBugz per il tracciamento dei bug, ma più generali sono le risposte, meglio è.

Il primo è il problema tecnico:esiste un'API per FogBugz?Esistono buoni tutorial o, meglio ancora, codice già scritto?

Il secondo è il problema procedurale:cosa dovrebbe inserire esattamente il CI nel bug tracker quando la build si interrompe?Forse:

Titolo:"#{last committer} ha interrotto la compilazione!"

Corpo:"#{ tracce di errori }"

Suppongo che questo presupponga la risposta a questa domanda:dovrei anche inserire interruzioni CI nel tracciamento dei bug?

Answer 1

Tutte le configurazioni CI con cui ho lavorato inviano un'e-mail (a un elenco), ma se lo desideri, soprattutto se il tuo team utilizza FogBugz come sistema di cose da fare, potresti semplicemente aprire un caso in FogBugz 6. Ha un'API che ti consente di aprire casi.Del resto, potresti semplicemente configurarlo per inviare l'e-mail all'indirizzo di invio e-mail del tuo FogBugz, ma l'API potrebbe consentirti di fare di più, come assegnare il caso all'ultimo committer.

Brianmi suggerisce che, se il tuo CI rileva un errore in un commit che aveva un numero di caso, potresti anche semplicemente riaprire il caso esistente.Come codificare un campo caso per ogni piccola cosa, però, c'è un punto in cui l'automazione CI potrebbe essere "troppo intelligente", sbagliare ed essere semplicemente fastidiosa.Aprire un nuovo caso potrebbe essere sufficiente.

E grazie:questo mi fa chiedere se dovrei provare a integrare il nostro Scimpanzé configurazione con il nostro FogBugz!

Answer 2

Nella mia azienda abbiamo recentemente adottato lo stack Atlassian (commerciale), incluso JIRA per il monitoraggio dei problemi e Bamboo per le build.Proprio come il mondo Microsoft (immagino che siamo un negozio Java), se ottieni tutti i tuoi prodotti da un unico fornitore ottieni il vantaggio di una stretta integrazione.

Per un esempio di come hanno realizzato l'interoperabilità, visualizza il loro file pagina di interoperabilità.

Basta scellino.In generale, posso riassumere il loro approccio generale come:

• Crea problemi nel tuo bug tracker (es:chiave di emissione di PROJ-123).
• Quando committi il ​​codice, aggiungi "PROJ-123" al tuo commento di commit per indicare quale bug viene corretto da questa modifica del codice.
• Quando il tuo server CI estrae il codice, scansiona i commenti di commit delle differenze.Registra tutte le stringhe che corrispondono alla regex delle chiavi di emissione.
• Al termine della compilazione, genera un report delle chiavi del problema trovate.

Nello specifico per il tuo secondo problema:

Il tuo CI non deve inserire nulla nel tuo bug tracker.Il bambù non inserisce nulla in JIRA.Invece, quelli di Atlassian hanno fornito un plugin a JIRA che effettuerà una chiamata API remota a Bamboo, ponendo la domanda "Bamboo, a quali build sono correlato (un problema di JIRA)?".Questo probabilmente è meglio spiegato con a immagine dello schermo.

Answer 3

CC viene fornito con un'utilità che ti avvisa quando le build falliscono, probabilmente non vale la pena registrare la build fallita in FogBugz: non è necessario tenere traccia dei problemi che vengono immediatamente risolti (come lo sarà la maggior parte delle build danneggiate)

Per procedere al contrario (FogBugz che mostra i check-in che hanno risolto il problema) è necessario un browser di repository basato sul Web: FogBugz è facile da configurare in modo che mostri le modifiche corrette.