Приветствую, коллеги! Надоело насиловать свой комп постоянной сборкой проекта? Тогда это статья для вас! Continuous Integration - 1В этой статье я постараюсь кратко и понятно изложить материал касательно Continuous Integration ( дальше просто CI ), отвечу на такие простые вопросы как: "Что это?", "Зачем?" и "Почему?" и приведу пример тестового проекта. Данная статья рассчитана на опытного пользователя, который как минимум знаком с Build System: Maven, умеет пользоваться Git'ом и знает как пушить проекты на GitHub;

"Что такое Continuous Integration?"

Посмотрим что нам на этот вопрос скажет Wiki: Непрерывная интеграция (CI, англ. Continuous Integration) — это практика разработки программного обеспечения, которая заключается в слиянии рабочих копий в общую основную ветвь разработки несколько раз в день и выполнении частых автоматизированных сборок проекта для скорейшего выявления потенциальных дефектов и решения интеграционных проблем. Страшно, не правда ли? Давайте попробуем объяснить этот термин простыми словами: Непрерывная интеграция - это система для сборки и автоматизированного тестирования программного обеспечения с определенными конфигами на определенных машинах с целью обнаружения багов и несовместимостей. Okey, no problem, с этим разобрались, но возникает следующий логический вопрос:

Зачем нам CI?

Просто представим, вы пишете не маленький проект, и возникает необходимость добавить/изменить функционал. Вы его успешно пишете, пишете тесты, запускаете, и вроде бы все отлично, но нет. Бывают ситуации когда изменение одной функциональности влияет на другую, другая на третью и так далее, пока где-то не проскочит бага и вылетит ошибка. Да, вы можете сказать это скорей всего плохо спроектированный проект, и возможно вы будете правы, но что если нет, и эти связи действительно должны быть? И что если вы пишете создаете проект не один, что зачастую так и бывает? Вы запустили тесты своего только что написанного функционала, и они дали положительный результат. Вы сделали быстренько commit, затем push куда-то и уже думаете как будете дома курить сигару попивая дорого виски, но нет. Увы, ваш коллега, или босс, неважно кто, говорит что из-за вашего коммита упала вся сборка. Вы с недоумением говорите что вы же программист, вы протестили все. Но зачастую просто нет времени постоянно тестить весь проект, и вы протестили лишь свой кусок кода, в который внесли изменения, а не всю сборку в целом. Здесь нам на помощь приходит CI. При каждом push на какой-либо ресурс, CI будет собирать ваш проект с нуля, запускать ВСЕ тесты, и только если все тесты пройдут и проект соберется, сборка получит статус passing. В противном случае у вас будет возможность сделать comeback, и посмотреть, что пошло не так. Итак, настало время задаться вопросом "Почему так и а не иначе?" и заглянуть на программную реализацию. Пример Как я уже говорил, статья рассчитана на тех, кто знаком с Maven и Git'ом. Поэтому я буду надеяться на то, что вы знаете как и что я делаю помимо настройки CI и т д.
  1. Во-первых, давайте создадим простой тестовый проект Maven и создадим в нем класс который выводит на экран "Hello World!" и выполняет какую-либо простую операцию, и напишем для этого класса самый простой тест.

    В результате у нас должна получится примитивная структура проекта:

    Continuous Integration - 2

    Все исходники будут на моем GitHub. Без разницы что вы напишете в своем Main, и какие будут тесты.

  2. Делаем push нашего проекта на GitHub.

  3. Теперь самое интересное. Из CI я выбрал Travis CI по причине его доступности и надежности. В качестве хостинга исходного кода Travis берет GitHub.

    Итак, заходим на сайт Travis CI и авторизируемся через GitHub. В профиле подключаем наш проект:

    Continuous Integration - 3

    Все готово для сборки при каждом push, но вопрос КАК собирать?

  4. Возвращаемся в нашу всеми любимую IDEA и создаем файл .travis.yml

    Данный файл отвечает за config сборки Travis. Рассмотрим наиболее популярную настройку:

    • Нужно указать language, на котором реализован проект;
    • Указать путь к directories что бы сборка выполнялась быстрее;
    • Указать способ notifications о успешной или не успешной сборке.

    Вот так примерно должен выглядеть типичный Travis config:

    # https://docs.travis-ci.com/user/languages/java/
    language: java
    jdk: oraclejdk9
    
    # Improve Build Speed https://dzone.com/articles/travis-ci-tutorial-java-projects
    cache:
      directories:
      - $HOME/.m2
    
    # Notifications https://docs.travis-ci.com/user/notifications/
    notifications:
      email:
        recipients:
          - qThegamEp@gmail.com
        on_success: always # default: change
        on_failure: always # default: always

    Я добавил комментарии, с ссылками для ясности.

  5. Делаем снова push на GitHub и открываем сайт Travis, выбираем проект и следим за сборкой. В итоге получаем уведомление об успешной сборке:

    Continuous Integration - 4 Continuous Integration - 5

    Также на сайте можем увидеть бейджик с успешной сборкой нашего проекта, который мы можем вставить в наш README.md:

    Continuous Integration - 6
Полезные ссылки: Могут быть ошибки, ОтЧиПяТкИ в тексте. Спасибо за внимание!