Continuous Integration

Приветствую, коллеги! Надоело насиловать свой комп постоянной сборкой проекта? Тогда это статья для вас! В этой статье я постараюсь кратко и понятно изложить материал касательно 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!" и выполняет какую-либо простую операцию, и напишем для этого класса самый простой тест.

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

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

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

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

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

   Все готово для сборки при каждом 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, выбираем проект и следим за сборкой. В итоге получаем уведомление об успешной сборке:

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

Полезные ссылки:

• Мой тестовый проект который вы можете посмотреть/скачать, если вдруг что-то не поняли;

• Собственно сам сайт Travis CI;

• Туториал на официальном сайте по настройке и использованию Travis CI;

• Хорошее видео;

• Еще один туториал;

• Следующая статья

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