Question

J'utilise cruisecontrol.rb pour CI et FogBugz pour le suivi des bogues, mais plus les réponses sont générales, mieux c'est.

Le premier est le problème technique :existe-t-il une API pour FogBugz ?Existe-t-il de bons tutoriels, ou mieux encore, du code pré-écrit ?

Deuxièmement, le problème de procédure :que doit exactement mettre le CI dans le système de suivi des bogues lorsque la version est interrompue ?Peut-être:

Titre:"#{last committer} a interrompu la construction !"

Corps:"#{ traces d'erreur }"

Je suppose que cela présuppose la réponse à cette question :devrais-je même intégrer des pauses CI dans mon suivi des bogues ?

Était-ce utile?

La solution

Toutes les configurations CI avec lesquelles j'ai travaillé envoient un e-mail (à une liste), mais si vous le souhaitez, surtout si votre équipe utilise FogBugz comme système de tâches, vous pouvez simplement ouvrir un dossier dans FogBugz 6. Il a une API qui vous permet d'ouvrir des dossiers.D'ailleurs, vous pouvez simplement le configurer pour envoyer l'e-mail à l'adresse e-mail de soumission de votre FogBugz, mais l'API peut vous permettre de faire plus, comme attribuer le cas au dernier committer.

BrianLa réponse de me suggère que si votre CI constate un échec dans une validation qui avait un numéro de dossier, vous pourriez même simplement rouvrir le dossier existant.Cependant, comme la codification d'un champ de cas pour chaque petite chose, il y a un point où l'automatisation du CI pourrait être « trop intelligente », se tromper et être simplement ennuyeuse.Ouvrir un nouveau dossier pourrait suffire.

Et merci:cela me fait me demander si je devrais essayer d'intégrer notre Les chimpanzés configuration avec notre FogBugz!

Autres conseils

Dans mon entreprise, nous avons récemment adopté la pile (commerciale) Atlassian, comprenant JIRA pour le suivi des problèmes et Bamboo pour les builds.Tout comme le monde Microsoft (je suppose que nous sommes une boutique Java), si vous obtenez tous vos produits auprès d'un seul fournisseur, vous bénéficiez du bonus d'une intégration étroite.

Pour un exemple de la manière dont ils ont réalisé l'interopérabilité, consultez leur page d'interopérabilité.

Assez de shillings.De manière générale, je peux résumer leur approche générale comme suit :

  • Créez des problèmes dans votre bug tracker (ex :clé d'émission de PROJ-123).
  • Lorsque vous validez du code, ajoutez « PROJ-123 » à votre commentaire de validation pour indiquer le bug que ce changement de code corrige.
  • Lorsque votre serveur CI extrait le code, scannez les commentaires de validation des différences.Enregistrez toutes les chaînes correspondant à l'expression régulière de vos clés de problème.
  • Une fois la construction terminée, générez un rapport sur les clés de problème trouvées.

Plus précisément à votre deuxième problème :

Votre CI n'a pas besoin de mettre quoi que ce soit dans votre outil de suivi des bogues.Bamboo ne met rien dans JIRA.Au lieu de cela, les gens d'Atlassian ont fourni un plugin à JIRA qui effectuera un appel d'API à distance dans Bamboo, posant la question "Bamboo, à quelles versions suis-je (un problème JIRA) lié ?".Ceci s'explique probablement mieux par un capture d'écran.

CC est livré avec un utilitaire qui vous avertit lorsque les builds échouent, cela ne vaut probablement pas la peine de consigner la build défaillante dans FogBugz - vous n'avez pas besoin de suivre les problèmes qui sont immédiatement résolus (comme le seront la plupart des builds défectueux)

Pour procéder dans l'autre sens (FogBugz affichant les enregistrements qui ont résolu le problème), vous avez besoin d'un navigateur de référentiel Web - FogBugz est facile à configurer pour qu'il affiche les bonnes modifications.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top