GitLab CI проти Jenkins [закрито]

Яка різниця між Дженкінсом та іншими CI, такими як GitLab CI, drone.io, що постачається з дистрибутивом Git. У деяких дослідженнях я міг прийти до висновку лише про те, що спільне видання GitLab не дозволяє додавати Дженкінса, але це корпоративне видання GitLab. Чи є інші суттєві відмінності?

Це мій досвід:

У своїй роботі ми управляємо нашими сховищами за допомогою GitLab EE і у нас працює сервер Jenkins (1.6).

В основі вони роблять майже те саме. Вони запускають деякі сценарії на зображенні сервера / Docker.

TL; DR;

• Дженкінс простіше у використанні / навчанні, але це ризикує стати пекельним плагіном
• Дженкінс має графічний інтерфейс (цьому можна віддати перевагу, якщо він повинен бути доступним / підтримуваним іншими людьми)
• Інтеграція з GitLab менша, ніж з GitLab CI
• Дженкінс можна розділити з вашого сховища

Більшість серверів CI є досить прямими вперед ( concourse.ci ), gitlab-ci , circle-ci , travis-ci , drone.io , gocd та що ще у вас є). Вони дозволяють виконувати сценарії shell / bat з визначення файлу YAML. Дженкінс набагато більш підключений і постачається з інтерфейсом користувача. Це може бути як перевагою, так і недоліком, залежно від ваших потреб.

Дженкінс дуже налаштований через усі доступні плагіни. Мінус цього полягає в тому, що ваш сервер CI може стати спагетті плагінів.

На мою думку, прив’язка та упорядкування робочих місць у Дженкінсі набагато простіші (завдяки інтерфейсу), ніж через YAML (виклик команд curl). Крім того, Jenkins підтримує плагіни, які встановлюватимуть певні двійкові файли, коли вони недоступні на вашому сервері (не знайте про це для інших).

В даний час ( Дженкінс 2 також підтримує більш «правильний» CI з Jenkinsfileі на pipline плагін , який поставляється по замовчуванням , як від Jenkins 2), але використовується , щоб бути менше , в поєднання зі сховищем , ніж тобто GitLab CI.

Використання файлів YAML для визначення вашої конвеєрної збірки (і врешті-решт з використанням чистої оболонки / bat) є більш чистою.

Доступні для Дженкінса плагіни дозволяють візуалізувати всі види звітів, такі як результати тестів, покриття та інші статичні аналізатори. Звичайно, ви завжди можете написати або використовувати інструмент, щоб зробити це для вас, але це, безумовно, плюс для Дженкінса (особливо для менеджерів, які схильні оцінювати ці звіти занадто багато).

Останнім часом я все більше працюю з GitLab CI. У GitLab вони роблять дійсно чудову роботу, роблячи весь досвід задоволенням. Я розумію, що люди користуються Дженкінсом, але коли у вас працює GitLab і він доступний, розпочати роботу з GitLab CI дуже просто. Не буде нічого, що інтегруватиметься так само легко, як GitLab CI, навіть якщо вони докладуть певних зусиль у сторонніх інтеграціях.

• Їх документація повинна розпочати роботу в найкоротші терміни.
• Поріг для початку дуже низький.
• Технічне обслуговування просте (без плагінів).
• Масштабування бігунів просте.
• CI повністю є частиною вашого сховища.
• Робота / погляди Дженкінса можуть стати безладними.

Під час написання запитів:

• Підтримка лише одного файлу у спільноті. Кілька файлів у корпоративній редакції .

Я погоджуюся з більшістю зауважень Ріка, але моя думка щодо того, що простіше, є протилежною : GitLab виявляється чудовим інструментом для роботи.

Більшість потужностей припадає на те, щоб бути автономними та інтегрувати все в одному продукті на одній вкладці браузера: від браузера сховища, дошки видань або історії складання до інструментів розгортання та моніторингу .

Я зараз використовую його для автоматизації та тестування того, як програма встановлюється на різних дистрибутивах Linux, і це просто чутно швидко налаштовується (спробуйте відкрити складну конфігурацію завдання Jenkins у Firefox і чекати, коли невідповідний сценарій з'явиться проти як легкий для редагування .gitlab-ci.yml).

Час, витрачений на налаштування / масштабування підлеглих, значно менший завдяки бінарним файлам бігуна ; плюс той факт, що на GitLab.com ви отримуєте цілком пристойних та безкоштовних спільних бігунів.

Після декількох тижнів, коли користувач GitLab CI є потужним користувачем, Дженкінс відчуває себе більш ручним , наприклад, копіювання завдань на відділення, встановлення плагінів для виконання простих речей, таких як завантаження SCP. Єдиний випадок, з яким я зіткнувся, де я пропускаю його, як сьогодні, - коли задіяно більше одного сховища; це ще треба добре розібратися.

BTW, я зараз пишу серію про GitLab CI, щоб продемонструвати, як не так складно налаштувати інфраструктуру CI вашого сховища. Опублікований минулого тижня, перший твір представляє основи, плюси та мінуси та відмінності з іншими інструментами: Швидка та природна безперервна інтеграція з GitLab CI

Перш за все, станом на сьогодні, GitLab Community Edition може бути повністю сумісний з Дженкінсом. Ніякого питання.

Далі я даю кілька відгуків про успішний досвід поєднання як Дженкінса, так і GitLab CI. Я також обговорю, чи слід використовувати обидва або тільки один із них, і з якої причини.

Сподіваюся, це дасть вам якісну інформацію про ваші власні проекти.

GitLab CI і Дженкінс сильні сторони

GitLab CI

GitLab CI природно інтегрований у GitLab SCM. Ви можете створювати конвеєри, використовуючи gitlab-ci.ymlфайли та управляти ними через графічний інтерфейс.

Ці конвеєри як код можуть очевидно зберігатися в кодовій базі, застосовуючи практику "все як код" (доступ, версія, відтворюваність, повторне використання тощо).

GitLab CI - це чудовий інструмент візуального управління:

• всі члени команд (включаючи нетехнічні) мають швидкий та простий доступ до статусу життєвого циклу додатків.
• тому його можна використовувати як інтерактивну та функціональну інформаційну панель для управління випуском.

Дженкінс

Дженкінс - чудовий інструмент побудови. Її сила в багатьох плагінах. Особливо мені пощастило використовувати плагіни інтерфейсу між Дженкінсом та іншими інструментами CI або CD. Це завжди кращий варіант, ніж переробити (можливо погано) діалоговий інтерфейс між двома компонентами.

Трубопровід як код також доступний за допомогою groovyскриптів.

Використання GitLab CI та Jenkins разом

Спочатку це може здатися трохи зайвим, але поєднання GitLab CI і Jenkins є досить потужним.

• Оркестри CI GitLab (ланцюги, запуски, монітори ...) і можуть скористатися його графічним інтерфейсом, інтегрованим до GitLab
• Дженкінс виконує завдання та полегшує діалог із сторонніми інструментами.

Ще однією перевагою цієї конструкції є слабке з'єднання між інструментами:

• ми могли б замінити будь-який з компонентів фабрики побудови без необхідності переробляти весь процес CI / CD
• ми можемо створити неоднорідне середовище побудови, поєднуючи (можливо, декілька) Дженкінс, TeamCity, ви його називаєте, і все ще маємо єдиний інструмент моніторингу.

Компроміс

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

З цієї причини я не рекомендую таке налаштування, якщо тільки

• у вас є багато сторонніх інструментів для вирішення. Ось тоді Дженкінс дуже корисний зі своїми численними плагінами.
• вам доводиться мати справу зі складними програмами з неоднорідними технологіями, маючи кожне інше середовище побудови, і все ж потрібно мати єдиний інтерфейс управління життєвим циклом додатків.

Якщо ви не перебуваєте ні в одній із цих ситуацій, вам, мабуть, краще тільки з одним із двох, але не з обома.

Якби мені довелося вибрати одну

І GitLab CI, і Jenkins мають свої плюси і мінуси. Обидва є потужним інструментом. Отже, яку вибрати?

Відповідь 1

Виберіть той, у якого ваша команда (або хтось із близьких) вже має певний рівень знань.

Відповідь 2

Якщо ви все є першокурсником CI-технологій, просто виберіть його та вирушайте.

• Якщо ви використовуєте GitLab і володієте вмінням у всьому коді, то вибираєте загальний сенс, щоб вибрати GitLab CI.
• Якщо вам доводиться вести діалог з багатьма іншими інструментами CI / CD або вам абсолютно потрібен графічний інтерфейс для створення своїх робочих місць, перейдіть до Дженкінса.

Ті з вас, хто використовує GitLab і не впевнені, що продовжуватимуть це, все ж повинні пам’ятати, що, вибравши GitLab CI, це означатиме, щоб вивести всі ваші конвеєри CI / CD.

Заключне слово: баланс трохи нахиляється до Дженкінса через багато плагінів, але шанси на те, що GitLab CI швидко заповнить прогалину.

Я хотів би додати деякі висновки з мого недавнього експерименту з GitLab CI. Особливості, які поставляються з 11.6 та 11.7, просто приголомшливі!

Зокрема, я люблю onlyумови, які в основному дозволяють будувати окремі трубопроводи для merge_requestабо push(повний перелік тут )

Також мені дуже подобається відсутність плагінів. Коли мені потрібна якась більш складна функціональність, я просто записую власне зображення Docker, яке обробляє необхідну функціональність (це та сама концепція, яку ви можете бачити в drone.io ).

Якщо вам цікаво DRY , це сьогодні абсолютно можливо! Ви можете написати свої "шаблони"

.myTemplate:
  image: node:10.14.2
  script:
    - npm install
    - npm run test

Помістіть їх у деякий загальнодоступний сховище, включіть їх у основний конвеєр:

include:
  - remote: https://....

І використовуйте їх, щоб продовжити якусь роботу:

test:
  extends: .myTemplate
  only:
    refs: ["master"]
    variables:
      - $CI_PIPELINE_SOURCE == "push"

Я так люблю GitLab CI! Так, він (поки що) не може малювати приємні графіки з покриттям тощо, але в цілому це дійсно акуратний інструмент!

Редагувати (02.02.2013): ось моя публікація про речі, які я люблю в GitLab CI. Він був написаний у 11.7 "епосі", тому, читаючи цю відповідь, у GitLab CI, ймовірно, є ще багато можливостей.

Редагувати (2019-07-10): Gitlab CI тепер підтримує декілька, extendsнаприклад

extends:
 - .pieceA
 - .pieceB

Перегляньте офіційну документацію, щоб отримати більше інформації про кілька розширень

якщо ваші завдання зі створення / публікації / розгортання та тестування не є дуже складними, використання gitlab ci має природні переваги.

Оскільки gitlab-ci.yml присутній поряд з кодом у кожній гілці, ви можете змінювати кроки ci / cd, зокрема тести (які відрізняються у різних середовищах) ефективніше.

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

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

більше того, gitlab ci автоматично перевірить вас, і вам не доведеться окремо керувати майстрами джинсинів