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

Question

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

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

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

Answer 1

Мы используем ТРАССА с SVN в нашей компании и выполнять ежедневные переходящие сборки в среды РАЗРАБОТКИ / ПРОМЕЖУТОЧНЫЕ и СТАБИЛЬНЫЕ с регулярными запланированными развертываниями (раз в месяц...ish) в ПРОИЗВОДСТВЕННУЮ среду.

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

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

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

Таким образом, проверка SVN ссылается на тикет...и билет ссылается на проверку SVN.

Затем наши ежедневные сборки выполняются с набором изменений SVN (напримерсегодняшняя сборка - это все, что зависит от набора изменений [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 совместно с TeamCity от JetBrains для CI.

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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