Автоматизированное управление версиями программного обеспечения, интегрированное с системой контроля ошибок - PullRequest
Новая
       87

Автоматизированное управление версиями программного обеспечения, интегрированное с системой контроля ошибок

0 голосов
/ 27 декабря 2011

Я решил использовать следующий шаблон после прочтения семантического управления версиями на http://semver.org/. Однако у меня есть некоторые нерешенные проблемы в плане автоматизации и интеграции инструментов SDLC. 

Version Pattern: 
major.minor.revision.build

такой, что;

Major: существенные изменения, должны быть увеличены вручную.
Незначительные: незначительные изменения, должны увеличиваться автоматически, всякий раз, когда новая система или расширение существующей функции решается в системе отслеживания ошибок.
Редакция: Изменения, не влияющие на незначительные изменения, должны увеличиваться автоматически при каждом устранении ошибки в системе отслеживания ошибок.

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

Кроме того, я добавляю инструмент непрерывной интеграции в эту конфигурацию и предполагаю, что это бамбук (кстати, я никогда раньше не использовал бамбук, я использовал Hudson), и я использую Eclipse IDE с плагином mylyn и плюс Проект является проектом Maven (веб).

Теперь я хочу объяснить, что я хочу сделать, иллюстрируя следующий сценарий. Аналитик (A) открывает проблему (I), которая является новой функцией, связанной с проектом Maven (P). Как разработчик (D), я получаю электронное письмо о проблеме и открываю задачу через интерфейс Mylyn в Eclipse. Я понимаю и разрабатываю новую функцию, связанную с проблемой (I). Предположим, я разработчик, ориентированный на тестирование, поэтому я написал тесты Unit, DBUnit и User-Acceptance (например, с использованием Selenium) соответственно. Наконец, я фиксирую изменения в системе контроля версий. Я думаю, что все остальное должно циклически автоматически, но я не знаю, как мне этого добиться? Авто-циклическая часть выглядит следующим образом:

Система управления исходным кодом должна иметь скрипт post-hook, который запускает инструмент непрерывной интеграции для построения проекта (P). При сборке на соответствующем этапе необходимо запустить тестовый код и сгенерировать их отчеты. Пользовательский приемочный тест должен быть выполнен на выделенном сервере (например, jboss или Tomcat). Порядок этого приемочного теста должен быть на сервере, запустить тест UA, затем сгенерировать отчеты о тестировании UA и отключить сервер. Если все эти шаги были успешно завершены, необходимо выполнить управление версиями. В части управления версиями плагин Maven или что-то еще должно принимать число проблем, решаемых с помощью системы отслеживания ошибок, и увеличивать связанные фрагменты версии (вспомогательные и ревизионные), наконец добавляя номер сборки. Фрагменты версии могут быть сохранены в файле манифеста, чтобы отобразить его в пользовательском интерфейсе. Наконец, что не менее важно, инструмент CI должен развернуть его в тестовой среде. Это все автоциклические процессы, которые я хочу.

Развертывание артефакта в производственной среде должно выполняться автоматически или вручную?

1 Ответ

0 голосов
/ 27 декабря 2011

Давайте начнем с дополнительного вопроса: при автоматическом развертывании в производство это требует подписи «бизнеса», кто бы это ни был.Насколько хороши ваши тесты для автоматического запуска в производство?Достаточно ли они хороши, чтобы вы доверяли вещам, чтобы просто жить?Какое у тебя время простоя?Это приемлемо?Если ваши тесты что-то пропустили, вы можете откатиться?Вы контролируете производство, чтобы знать, если у вас возникли проблемы?Как правило, ответы на достаточное количество этих вопросов достаточно отрицательны, поэтому вы не можете выполнить автоматическое развертывание там в результате события build / autotest.

Что касается отслеживания, вам понадобится несколько вещей.Вам понадобятся все ваши предположения, чтобы быть правдой (я сомневаюсь, что они верны, но если вы доберетесь туда, это здорово).Вам также понадобится номер сборки, который можно увеличить по истечении времени сборки на основе результатов теста.Вам понадобятся исходные изменения, которые будут помечены идентификаторами ошибок.Вам понадобится система сборки, чтобы проанализировать исходные изменения и связать их с проблемами.Вам понадобится API в системе сборки, чтобы вы могли получить количество проблем, связанных со сборкой.Наконец, вам понадобится ваш собственный скрипт, чтобы выполнить запрос и соответствующим образом обновить номер сборки.

  • Это вполне выполнимо, но действительно ли оно того стоит?Какое значение вы придаете схеме нумерации?
...