Может ли продвижение филиала Hudson основываться на стабильности проекта?

Question

Сервер Hudson CI отображает стабильность «погоды», что круто. И это позволяет начать сборку одного проекта на основе успешной сборки другого. Однако как вы можете сделать этот вторичный проект зависимым от стабильности нескольких сборок первого проекта?

В частности, проект "stable_deploy" должен запускаться только для продвижения версии до "stable", если проект "интегрируется" с версией 8.3.4.1233 успешно собран и протестирован не менее 8 раз - подряд. До этого он все еще находится в режиме интеграции.

ВАЖНО: Важным предупреждением для этого является то, что один набор проектов Hudson используется в качестве «конвейера» для обработки каждой новой версии до выпуска. Таким образом, проект может быть успешно собран 8 раз за раз, но последняя версия 8.3.4.1233 может быть только двумя самыми последними сборками. Сборки до этого могут быть более ранней версией.

Мы готовы полностью реорганизовать это, но идея конвейера, казалось, значительно сократила объем создания и удаления проекта вручную. Есть ли лучший способ отслеживать выпуск версии "конвейера"? В частности, в будущем у нас будет несколько версий в этом конвейере одновременно из-за исправлений или исправлений для более старых версий. Мы пока не видим, как это сделать, за исключением создания новых конвейерных проектов для каждой версии, что создает большие трудности.

Вот некоторые детали фона:

Приложение TickZoom имеет несколько очень полных модульных тестов, некоторые из которых имитируют торговую среду в реальном времени. Добавьте к этому, TickZoom тщательно использует распараллеливание для использования многоядерных компьютеров. Само собой разумеется, что при разработке новой версии могут возникнуть проблемы со стабильностью во время интеграционного тестирования, которые обнаруживаются при многократном запуске сборки и автоматических тестов. Версия, которая собирает и тестирует чисто 8 раз подряд без изменений, а также прошла некоторое реальное тестирование пользователями, может считаться «стабильной» и переведена в стабильную ветвь.

Наши проекты Hudson выглядят так:

test - только для тестирования сборки, нулевая видимость пользователя. integrate_deploy - продвигает сборку тестового проекта для интеграции ветки и делает ее доступны для публичного тестирования на UA. интегрировать - неоднократно строит ветку интеграции, чтобы определить, достаточно стабильный, чтобы продвинуться к стабильной отрасли. Это запускает строит и тестирует ежечасно в течение каждой ночи. stable_deploy - продвигает интегрированную сборку проекта в стабильную ветку и делает его общедоступным для пользователей, которые хотят, чтобы последние и лучшие. stable - создает стабильную ветку раз в ночь После 2 недель успешные сборки (14 сборок) можно перейти к «релиз-кандидату».

И так далее ... это продолжается с "релиз-кандидат", а затем "релиз".

Answer 1

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

Таким образом, они будут такими:

integrate_0.8.3 stable_0.8.3 кандидат_0.8.3 release_0.8.3

Мы будем использовать API-интерфейс Hudson для создания заданий для каждой новой версии со сценарием.

Повышение не может быть полностью автоматизировано, поскольку другие факторы, кроме стабильных сборок, такие как пользовательсообщенные ошибки могут задержать перемещение версии по конвейеру.

искренне, Уэйн

Answer 2

Я вижу смысл демонстрировать стабильность, если множественные последовательные сборки выполняются без ошибок, но я бы предложил немного другой подход, чтобы сделать вещи проще. Вместо того чтобы пытаться объединить результаты нескольких сборок, чтобы определить, продвигаете ли вы последнюю сборку в стабильную ветвь, запустите тесты 8 раз для одной и той же сборки; Вы можете сделать это, добавив параметр счетчика повторений в тесты, или просто повторить шаги теста несколько раз в настройке задания Hudson.

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

Это имеет пару преимуществ; это делает установку Hudson более простой в соответствии с вашим запросом, и это дает вам дополнительную уверенность в стабильности сборки, поскольку вы выполняете тесты несколько раз на одной и той же базе кода, а не на другой базе кода каждый раз. 1005 *

Answer 3

Полагаю, вам нужно либо внедрить какое-то решение за пределами Hudson, которое создает файлы триггеров для использования в Hudson, либо расширить плагин для продвижения по правилам вашей компании.