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


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


    Зачем?


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

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

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


    А недостатки какие?

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


    Примеры


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

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

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

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

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

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

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

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

    Заключение


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

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

    Комментарии 6

      0
      В прошлом посте я хотел познакомить хабражителей с buildbot'ом. Но тема была мной раскрыта не до конца.

      Блин, да ладно.
        +2
        картинка реально поднадоела
          +4
          >> Если у Вас большой и сложный проект, то скорее всего ни одна система непрерывной интеграции из коробки не даст Вам то, чего вы хотите.
          Может конечно включаю режим капитана очевидность но по хорошему большой и сложный проект должен собиратся «одним нажатием клавиши» в полном цикле (апдейт версий, генерация документации, запуск тестов, создание тагов и так далее) и без билд машины (и соотвественно без системы непрервыной интеграции которая выше уровнем). В таком случае системы непрерывной интеграции по сути становятся job schedulerами с разными удобностями:
          1) триггер билда/job по коммиту, мониторинг исходного кода
          2) сохранение артефактов в удобные места (tm)
          3) красивые отчеты в вебе и сбор всякой ненужной но красивой статистики
          4) визуализация результатов юнит тестов
          5) массовый россыл мейлов при сломе билда или тестов (а иногда и просто так)
          6) интеграция с багтрекингом (отметить какие тикеты попали в какой билд и так далее)
          7) и тому подобное
          И вся магия таких систем обычно состоит в том как сложно эти штуки настроить. Главное не пытатся из нее выдавить то что она не должна делать (заниматся сборкой отдельных компонентов, лезть в зависимости между внутренними модулями проекта, прыгать на уровень cmake/ninja/autotools etc).

            +1
            Во многом согласен, но:
            1) Общий продукт может состоять из нескольких совершенно разных приложений
            2) И все эти приложения может быть необходимость собирать под разные платформы
            3) Плюс ко всему этому нам может понадобится впиливать кастомные хуки, скрипты и прочее.
            Вот в таких случаях можно смотреть в сторону buildbot.

            И да, все это можно делать и в дженкинсе, но не всегда удобно. Серебряной пули не существует, но я хотел показать инструмент, который позволяет в некоторых случаях её для себя создать.
            +1
            На success stories где-то страницы мертвые, где-то вместо билдбота уже дженкинс(http://buildbot.nodejs.org/)
              0
              И правда ведь. Пойду им в джиру отпишусь.

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

            Самое читаемое