Continuous Integration вместе с buildbot: а зачем?

в 11:25, , рубрики: buildbot, continuous integration, framework, open source, python, тестирование, метки: , , ,

Continuous Integration вместе с buildbot: а зачем?
В прошлом посте я хотел познакомить читателей с buildbot'ом. Но тема была мной раскрыта не до конца.
Сегодня я постараюсь немного наверстать упущенное.

Зачем?

Если у Вас большой и сложный проект, то скорее всего ни одна система непрерывной интеграции из коробки не даст Вам то, чего вы хотите. И тут все выкручиваются как могут: кто-то пишет плагины, кто-то городит костыли. И, увы, второй вариант встречается достаточно часто. Это может быть связанно с тем, что выбранная CI система не обладает достаточной гибкостью.

Что нам дает buildbot?

  • Вся выразительная мощь python'а в конфиге сборки
  • Раз конфиг есть код, то мы можем положить его в гит
  • Ну а к гиту можно прикрутить и код ревью
  • Расписание сборок, связанный запуск
  • Поддерживает все современные VCS
  • Можно сделать все так, как хочешь
  • JSON api
А недостатки какие?

  • Нет красивых кнопочек(пока)
  • Настройка нетривиальна
  • Документация так себе
  • Русскоязычного комьюнити почти нет
  • Много писать самому

Примеры

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

Генерируем сборки

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

Самообновление

Хорошей практикой будет положить все конфиги вашего мастер-сервера в git и поручить билдботу обновлять самого себя.
Тогда уменьшится вероятность того, что вы что-то случайно сломаете, особенно если у Вас в фирме используется практика код-ревью.
Делается это примерно по следующей схеме:

  • Ставим рядышком с мастером новый слейв
  • Создаем билдер и поручаем ему следить за репозиторием, в котором лежат наши конфиги
  • Если в репозитории появилось что-нибудь новенькое, то мы забираем изменения и реконфигурируем мастер

Реализацию подобной схемы можно посмотреть тут.

Разделяй и властвуй

На мой взгляд хранить конфиги всех сборок в одном файле очень неудобно. Но и каждый раз лезть в править мастер-конфиг, чтобы добавить в него новый импорт тоже радости не доставляет.
Для себя лично я написал вот такую реализацию загрузчика, который автоматом подхватывает конфиги из определенной папки.

Заключение

Скорее всего этого недостаточно, чтобы заинтересоваться билдботом. От того настоятельно рекомендую посетить сайт проекта и посмотреть список success stories.

И если Вас по каким-либо причинам не устраивает ваша текущая система непрерывной интеграции, то я предлагаю обратить внимание на buildbot. По мне так он того стоит.
С удовольствием отвечу на вопросы.

Автор: HgeN

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js