Comments 6
В прошлом посте я хотел познакомить хабражителей с buildbot'ом. Но тема была мной раскрыта не до конца.
Блин, да ладно.
Блин, да ладно.
картинка реально поднадоела
>> Если у Вас большой и сложный проект, то скорее всего ни одна система непрерывной интеграции из коробки не даст Вам то, чего вы хотите.
Может конечно включаю режим капитана очевидность но по хорошему большой и сложный проект должен собиратся «одним нажатием клавиши» в полном цикле (апдейт версий, генерация документации, запуск тестов, создание тагов и так далее) и без билд машины (и соотвественно без системы непрервыной интеграции которая выше уровнем). В таком случае системы непрерывной интеграции по сути становятся job schedulerами с разными удобностями:
1) триггер билда/job по коммиту, мониторинг исходного кода
2) сохранение артефактов в удобные места (tm)
3) красивые отчеты в вебе и сбор всякой ненужной но красивой статистики
4) визуализация результатов юнит тестов
5) массовый россыл мейлов при сломе билда или тестов (а иногда и просто так)
6) интеграция с багтрекингом (отметить какие тикеты попали в какой билд и так далее)
7) и тому подобное
И вся магия таких систем обычно состоит в том как сложно эти штуки настроить. Главное не пытатся из нее выдавить то что она не должна делать (заниматся сборкой отдельных компонентов, лезть в зависимости между внутренними модулями проекта, прыгать на уровень cmake/ninja/autotools etc).
Может конечно включаю режим капитана очевидность но по хорошему большой и сложный проект должен собиратся «одним нажатием клавиши» в полном цикле (апдейт версий, генерация документации, запуск тестов, создание тагов и так далее) и без билд машины (и соотвественно без системы непрервыной интеграции которая выше уровнем). В таком случае системы непрерывной интеграции по сути становятся job schedulerами с разными удобностями:
1) триггер билда/job по коммиту, мониторинг исходного кода
2) сохранение артефактов в удобные места (tm)
3) красивые отчеты в вебе и сбор всякой ненужной но красивой статистики
4) визуализация результатов юнит тестов
5) массовый россыл мейлов при сломе билда или тестов (а иногда и просто так)
6) интеграция с багтрекингом (отметить какие тикеты попали в какой билд и так далее)
7) и тому подобное
И вся магия таких систем обычно состоит в том как сложно эти штуки настроить. Главное не пытатся из нее выдавить то что она не должна делать (заниматся сборкой отдельных компонентов, лезть в зависимости между внутренними модулями проекта, прыгать на уровень cmake/ninja/autotools etc).
Во многом согласен, но:
1) Общий продукт может состоять из нескольких совершенно разных приложений
2) И все эти приложения может быть необходимость собирать под разные платформы
3) Плюс ко всему этому нам может понадобится впиливать кастомные хуки, скрипты и прочее.
Вот в таких случаях можно смотреть в сторону buildbot.
И да, все это можно делать и в дженкинсе, но не всегда удобно. Серебряной пули не существует, но я хотел показать инструмент, который позволяет в некоторых случаях её для себя создать.
1) Общий продукт может состоять из нескольких совершенно разных приложений
2) И все эти приложения может быть необходимость собирать под разные платформы
3) Плюс ко всему этому нам может понадобится впиливать кастомные хуки, скрипты и прочее.
Вот в таких случаях можно смотреть в сторону buildbot.
И да, все это можно делать и в дженкинсе, но не всегда удобно. Серебряной пули не существует, но я хотел показать инструмент, который позволяет в некоторых случаях её для себя создать.
На success stories где-то страницы мертвые, где-то вместо билдбота уже дженкинс(http://buildbot.nodejs.org/)
Sign up to leave a comment.
Continuous Integration вместе с buildbot: а зачем?