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;

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

• Ще один туторіал ;

• Наступна стаття

Можуть бути помилки, ВІДЧИП'ЯТКИ в тексті. Дякую за увагу!