Тестирование кода перед коммитом с помощью Jenkins и IDE от Jetbrains (IDEA, PhpStorm...)

    В этой статье я хочу расказать о настройке Jenkins'а и практически любой IDE от Jetbrains для так называемого Pre-Tested Commit. Pre-Tested Commit — это процесс тестирования изменённого кода перед комитом, в котором разработчик на основе локальных изменений формирует diff, загружает его в Jenkins и проверяет что билд проекта с его изменениями проходит успешно. После этого разработчик фиксирует изменения в репозитории.

    Начнём с настройки Jenkins. Для этого нам понадобится Patch Parameter Plugin.

    Устанавливаем его в Jenkins.



    После установки плагина настраиваем конкретную job'у для возможности передавать в неё патч с изменениями.



    Обратите внимания на настройку «Check-out Strategy». Перед каждым новым билдом нам нужно откатывать пришедшие с патчем изменения с помощью «svn revert».

    После настройки джобы мы можем загрузить патч прямо через интерфейс Jenkins'а.



    Но это не очень удобно, поэтому мы пойдём дальше и настроим возможность запускать билды с изменениями прямо из IDE. Для этого нам понадобится плагин Jenkins Control Plugin с поддержкой Patch Parameter Plugin.

    Скачиваем его отсюда и устанавливаем в IDE.



    После установки идём в настройки плагина.



    В настройках устанавливаем адрес Jenkins'а и суффикс, добавляемый к пути файлов в diff'е. Обновление списка jobs рекомендую установить в 1 минуту для оперативности оповещения о результатах билда.



    Всё! Теперь мы можем запускать билды с локальными изменениями прямо из IDE.

    Через загрузку файла патча.



    Или сразу на основе Changelist'а создавать патч и запускать с ним билд.



    Статус билда отображается рядом с именем Changelist'а.



    Спасибо за внимание и стабильных билдов!

    Patch Parameter Plugin
    Jenkins Control Plugin с поддержкой Patch Parameter Plugin

    p.s. Пожелания и замечания по плагину к IDE принимаются.

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

      –8
      Чего только не придумают, лишь бы DVCS не использовать.
        +11
        Процесс Pre-Tested Commit никак не завязан на типе VCS.
          +1
          Ух минусов-то насовали. А объяснить?

          Поясню свою позицию. Pre-Tesred Commi суть костыль на случай, когда коммитить по какой-то причине нельзя, а результат интеграции узнать хочется. «Какая-то причина» в случае с CVCS — сама система контроля версий,

          Я в Jenkins'е не волоку, но тот же Bamboo, например, умеет использовать Build Plan «родительской» ветки для веток «дочерних». Это позволяет каждому разработчику разносить свою ветку (или форк) вдребезги и пополам, запускать билды для _конкретных_ ревизий (а не для непонятно чего в виде патча) и не тревожить mainline.

          С форками в CVCS мы все знаем, как обстоит. С бранчами несколько лучше, но тоже не сахар. Посему таковой функционал — лучшее, что можно предложить в случае с CVCS.
            0
            Насколько я понимаю, суть не в самих коммитах, а в тестировании кода. Поэтому тут VCS вообще ни при чём.
              0
              А патчи кто делать будет?
                0
                Это уже другой вопрос.
            0
            Почему? Я даже спрошу — а зачем он нужен вообще? Почему нельзя коммитить в отдельный бранч и проверять его?
              0
              Например, чтобы уменьшить число коммитов-фиксов по результатам прохождения интеграционных тестов. Да и вообще держать постоянно любой билд в статусе успешной сборки — хорошая практика.
                0
                Зачем уменьшать число коммитов? Что это дает? Если всегда работать над фичей в отдельном бранче, то количество коммитов не важно. Держать в статусе успешной — ну не знаю, для этого Jenkins и придуман, чтобы автоматически тестировать билд. В принципе, это задача девелопера перед коммитом прогнать все тесты локально. Ну или закоммитить в бранч и работать над другой задачей, пока Jenkins оттестирует все.
                  0
                  Ну, это — ваше решение (ваших лидов). Делать стабильные законченные коммиты или коммиты, которые рушат половину интеграционных тестов + за ним коммитить пачку фиксов.
                    0
                    Я так понял, задача стоит делать стабильные законченные коммиты в транк. А каким образом это делается — через feature branches или через pre commit tests, дело десятое.
                      0
                      И не забываем ещё про cherry-pick'и части функционала в другую ветку. В вашем случае это будет захватывать пачку фикс-коммитов, которые нужно ещё найти.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      +1
                      При мерже они все перейдут в продакшен ветку, если не предпринимать специальных мер.
                0
                Мне даже интересно стало увидеть ход ваших мыслей. Как вы завязываете одно на другом.

                upd: я буду обновлять комментарии, перед отправкой своих. Спасибо, ответ получил.
                +1
                все понимаю, уважаю, но
                настраиваем конкретную джобу

                просто ужасно.
                  0
                  зануда =)
                  –1
                  Leerooooy Jenkins! Извините.
                  • НЛО прилетело и опубликовало эту надпись здесь

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

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