Непрерывная интеграция: как вы связываете свои сборки с требованиями / задачами / ошибками?

Question

Как вы отвечаете на следующие вопросы от менеджеров, тестировщиков и других людей в вашей команде:

В какой сборке исправлена ​​ошибка № 829? Какие задачи были выполнены в нашей текущей тестовой сборке?

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

Answer 1

Мы используем TRAC с SVN в нашей Компании и выполняем ежедневные непрерывные сборки в средах DEV / STAGING & STABLE с регулярными запланированными развертываниями (раз в месяц ... иш) для ПРОИЗВОДСТВЕННАЯ СРЕДА.

Когда сообщается об ошибке, она вводится в TRAC и получает номер билета (например, # 1001)

Когда ошибка устранена, код возвращается в SVN с номером билета (# 1001) в примечаниях по проверке SVN.

Разработчик запоминает номер набора изменений SVN (например, [5000]) и открывает веб-интерфейс TRAC. Закрывая билет, они помещают номер набора изменений в примечания к билету.

Таким образом, регистрация SVN ссылается на билет ..., а билет ссылается на регистрацию SVN.

Затем наши ежедневные сборки выполняются с использованием SVN Changeset (например, сегодняшняя сборка - это все, что нужно для изменения [5050]), и об этом говорится в нашем уведомлении о внедрении.

Deployed On   |  Environment            | Changeset
--------------+-------------------------+--------------------------
10-01-2008    |  DEV                    | 5100
10-01-2008    |  STAGING                | 5080
10-01-2008    |  STABLE                 | 5050
01-01-2008    |  PRODUCTION             | 5000

Таким образом, тестеры при рассмотрении исправлений для тестирования узнают по наборам изменений в комментариях к заявке, включает ли сборка, на которую они смотрят, исправление.

Answer 2

Мы используем TFS в сочетании с TeamBity для CI JetBrains.

При связывании регистрации с задачами наша пользовательская политика регистрации добавляет к задачам регистрации связанные задачи и ошибки с их идентификаторами и названиями.

Эти комментарии затем используются для создания заметок о выпуске, которые автоматически создаются для каждой сборки.

Answer 3

Мы используем Fogbugz, который имеет встроенную интеграцию Subversion. В основном есть плагин для Fogbugz, который проверяет проверки SVN в фоновом режиме. Поэтому, если вы указываете идентификатор Fogbugz-case при регистрации, он автоматически связывается с этой регистрацией.

Насколько я знаю, вам не нужно никаких специальных приложений (например, Beanstalk).

Другой способ немного сложнее. В нашей компании существует соглашение, согласно которому для каждой (будущей или прошлой) сборки существует «релиз» в Fogbugz. Если вы исправляете ошибку или внедряете функцию, вы назначаете случай правильной версии.

Тогда довольно просто получить список всех реализованных функций сборки X.

Answer 4

Мы используем управляемый сервис SVN под названием Beanstalk (http://www.beanstalkapp.com/)), который позволяет вам легко связываться с рядом систем управления ошибками / функциями. В нашем случае мы используем FogBugz Fog Creek для этих целей. SVN / Beanstalk позволяет вам делать заметки, когда вы регистрируете сборку, что, в свою очередь, влияет на состояние одного или нескольких FogBugz случаев.

На стороне клиента мы используем Tortoise SVN и Visual SVN для управления взаимодействием локального клиента и сервера Beanstalk SVN (Tortoise предоставляет реальный сервис, Visual SVN обеспечивает интеграцию между Tortoise SVN и MS Visual Studio).

Я настоятельно рекомендую обе службы и клиент Tortoise / Visual SVN.

Answer 5

Мы помечаем регистрацию в системе контроля версий с номером исправленного дефекта или номером расширения, который был внедрен.

Получив журнал регистрации между двумя сборками, вы можете определить, что было реализовано или исправлено.