Как мне интегрировать мою систему непрерывной интеграции с моей системой отслеживания ошибок?

Я использую cruisecontrol.rb для CI и FogBugz для отслеживания ошибок, но чем более общие ответы, тем лучше.

Во-первых, техническая проблема: есть ли API для FogBugz? Есть ли хорошие учебники или, что еще лучше, заранее написанный код?

Во-вторых, это процедурная проблема: что именно CI должен помещать в трекер ошибок, когда сборка прерывается? Возможно:

Заголовок: "# {последний коммиттер} сломал сборку!"

Тело: "# {следы ошибок}"

Полагаю, это предполагает ответ на вопрос: следует ли мне вообще включать CI-перерывы в отслеживание ошибок?


person James A. Rosen    schedule 16.08.2008    source источник


Ответы (3)


Все настройки CI, с которыми я работал, отправляют электронное письмо (в список), но если вы хотите - особенно если ваша команда использует FogBugz как систему задач - вы можете просто открыть кейс в FogBugz 6. В нем есть API, который позволяет открывать дела. В этом отношении вы можете просто настроить его для отправки электронного письма на ваш адрес электронной почты FogBugz, но API может позволить вам сделать больше, например, назначить дело последнему коммиттеру.

Ответ Брайана подсказывает мне, что если ваш CI обнаружит сбой в фиксации с номером дела, вы может даже просто заново открыть существующее дело. Однако, как и в случае кодирования поля для каждой мелочи, есть момент, когда автоматизация CI может быть «слишком умной», ошибаться и просто раздражать. Открытия нового дела может быть достаточно.

И спасибо: это заставляет меня задуматься, стоит ли мне попробовать интегрировать наши Chimps настройте с помощью нашего FogBugz!

person markpasc    schedule 16.08.2008

В моей компании мы недавно внедрили (коммерческий) стек Atlassian, включая JIRA для отслеживания проблем и Bamboo для сборок. Как и в мире Microsoft (я предполагаю - мы магазин Java), если вы получаете все свои продукты от одного поставщика, вы получаете бонус в виде тесной интеграции.

Чтобы увидеть, как они реализовали совместимость, просмотрите их страница совместимости.

Хватит шиллинга. В общем, я могу резюмировать их общий подход следующим образом:

  • Создайте проблемы в вашем трекере ошибок (например: ключ выпуска PROJ-123).
  • Когда вы фиксируете код, добавьте «PROJ-123» в комментарий коммита, чтобы указать, какую ошибку исправляет это изменение кода.
  • Когда ваш CI-сервер проверяет код, просканируйте коммит-комментарии к файлам diff. Запишите любые строки, соответствующие регулярному выражению ключей вашей задачи.
  • Когда сборка завершится, сгенерируйте отчет о том, какие ключи проблемы были найдены.

Конкретно к вашей второй проблеме:

Вашему CI не нужно ничего помещать в ваш трекер ошибок. Bamboo ничего не добавляет в JIRA. Вместо этого люди из Atlassian предоставили JIRA плагин, который будет выполнять удаленный вызов api в Bamboo, задавая вопрос «Bamboo, к каким сборкам я (проблема JIRA) относится?». Вероятно, лучше всего это объяснить с помощью снимка экрана снимок экрана.

person Brian Laframboise    schedule 16.08.2008

CC поставляется с утилитой, которая предупреждает вас о сбое сборки, вероятно, не стоит регистрировать сбойную сборку в FogBugz - вам не нужно отслеживать проблемы, которые сразу же решаются (как и большинство сломанных сборок)

Чтобы пойти другим путем (FogBugz показывает отметки, которые устранили проблему), вам понадобится браузер репозитория на базе Интернета - FogBugz легко настроить, чтобы он отображал правильные изменения.

person Keith    schedule 16.08.2008