Expert JS React Developers for TUI wanted. Join Ciklum and get a $4000 sign-on bonus!
×Закрыть

Порівнюємо інструменти для CI/CD: Teamcity, Jenkins, Bitbucket та інші

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Мене звуть Ганна Каплун, я Test Engineering Lead в Intellias. Ця стаття написана у співавторстві з Дмитром Ведецьким та Володимиром Похилою, DevOps-інженерами в Intellias. Матеріал буде корисний девопсам та всім, хто починає роботу над проєктом і думає, яку саме систему безперервної інтеграції обрати. Вибір такої системи може бути доволі складним, адже наразі доступно багато різних інструментів безперервної інтеграції. Деякі з них користуються більшою популярністю, ніж інші, але це ще не означає, що саме вони ефективніше розв’язуватимуть задачі вашого проєкту. Отже, є сенс порівняти їхні переваги та недоліки, а також розглянути фактори, які впливатимуть на ваш вибір. Саме про це й поговоримо.

Як обрати інструмент безперервної інтеграції

Для того, щоб зробити вдалий вибір, варто визначитися з критеріями, які можуть бути важливими:

— Хостинг. Інструменти з хмарним хостингом, тобто, на базі обладнання провайдера, мають певні переваги. Їх майже не потрібно конфігурувати та можна легко змінювати параметри оточення саме під ваші потреби. Відповідно, такі рішення легко масштабувати. Звісно ж, є продукти, які можна хостити локально, що може бути безпечнішим. У цьому випадку обов’язок з розгортання та підтримки системи припадає на девопс команду.

— Інтеграція та підтримка інших програм. Як система безперервної інтеграції взаємодіє з іншими інструментами, що використовуються в процесі розробки? Наприклад, для проєктного менеджменту (Jira), моніторингу інцидентів (PagerDuty), статичного аналізу коду тощо. Дуже важливою є підтримка білд-інструментів (типу Make, Shell Scripts, Ant, Maven, Gradle) та систем контролю версій (Subversion, Perforce, Git).

— Зручність у користуванні. Легкість у засвоєнні та зрозумілість інтерфейсу можуть сильно впливати на кількість часу, що потрібно витратити на ознайомлення з системою.

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

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

Зупинимося детальніше на п’яти найпопулярніших системах: Jenkins, TeamCity, Bamboo, GitLab та Azure DevOps.

1. Jenkins — найпопулярніша система безперервної інтеграції.

Jenkins — система з відкритим кодом, написана на Java, що працює на Windows, macOS та інших Unix-подібних операційних системах. Вона безкоштовна. Цю систему використовують дуже багато людей, що означає — ви завжди знайдете когось, хто зможе вам допомогти. Jenkins має інтеграцію з Docker та Kubernetes. Скоріш за все, ця система перша спадатиме вам на думку, коли йдеться про безперервну інтеграцію.

Основні переваги: Основні недоліки:

— Це безкоштовно — можете витратити свій бюджет на щось інше;
— Інтеграція майже з чим завгодно. Вбудована можливість використання контейнерів. Величезна бібліотека плагінів, в тому числі для Git, Gradle, Subversion, Slack, Jira, Redmine, Selenium, Pipeline, ваш варіант. Плагіни покривають п’ять основних сфер: платформи, інтерфейс, адміністрування, управління кодом, управління збірками. Жодна інша система безперервної інтеграції не може похвалитися таким різноманіттям;
— Jenkins має інтерфейс, через який можна легко створити білди/джоби/pipelines. То може бути як звичайний білд, так і pipelines (scripted-pipeline або declarative pipeline). Є можливість зберігати Pipeline в git (IaC);
— Активна спільнота. Велика кількість матеріалів — і не лише для початківців — та навіть щорічна конференція;
— Розподілення навантаження по різних машинах. Використовується Master-Slave архітектура, де основна машина (Master) контролює віддалені машини, на яких виконуються збірки, або запускаються тести (Slaves), відповідно розподіляючи навантаження.

— Документації не завжди достатньо. Певні задачі (наприклад, переробити фрістайл джоби на скриптові пайплайни) потребують часу;
— Застарілий інтерфейс. Тут не завжди виконуються сучасні принципи дизайну. Піксельні іконки, скупчення елементів інтерфейсу, відсутність автоматичного оновлення в деяких випадках — все це виглядає не дуже сучасно;
— Моніторинг мастер-сервера та слейвів треба здійснювати вручну. Треба розуміти, як взаємодіють між собою плагіни, машини, які версії де встановлені, та періодично це все оновлювати;
— Відсутність хмарного рішення.

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

2. TeamCity — також популярний інструмент безперервної інтеграції

TeamCity — надійна та високоякісна система. Багато що в ній підтримується за замовчуванням (різні функції, що пов’язані з аутентифікацією, тестуванням, розгортанням, контейнеризацією тощо). Є підтримка Docker, Windows, Linux, macOS, Solaris, FreeBSD, IBM z/OS, HP-UX. Все працює відразу після інсталяції, ніяких додаткових налаштувань не потрібно, є корисні переваги, на кшталт деталізованої історії, детального зворотного зв’язку при падінні тестів, відсутності дублювання коду (перевикористання за однакових налаштувань).

Основні переваги: Основні недоліки:

— Підтримка .NET. В цій системі найкраща підтримка для .NET з усіх наявних. Відразу доступні інструменти статичного аналізу, покриття та тестування коду;
— Система підтримує дуже широкий спектр систем контролю версій: AccuRev, ClearCase, CVS, Git, Gnu bazaar, Mercurial, Perforce, Borland StarTeam, Subversion, Team Foundation Server, SourceGear Vault, Visual SourceSafe, IBM Rational ClearCase. Для всього іншого є плагіни;
— Детальна та зрозуміла документація;
— Легко розгорнути. Безпосередньо після встановлення доступна велика кількість функцій;
— Вбудовані функції. Багато зручних та корисних функцій доступні всередині самої системи, без додаткових плагінів. Детальна історія, можливість перезапуску тестів, що впали, безпосередньо після завершення збірки, розгортання на будь-яких платформах тощо;
— Підтримка хмарного рішення — TeamCity Cloud.

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

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

3. Bamboo: інтеграція з продуктами Atlassian

Окрім власне інтеграції, Bamboo можна використовувати для збірки, розгортання застосунків, управління релізами. Звісно ж, основна перевага — це нативна інтеграція з продуктами Atlassian: Bitbucket, Jira та Confluence. Аналогічна інтеграція для умовного Jenkins досягається за допомогою декількох плагінів. Bamboo можна встановити на Windows, Linux (варто створити окремого користувача), Solaris та macOS.

Основні переваги: Основні недоліки:

— Пайплайни Bitbucket Bitbucket пайплайни — рішення для управління Git-репозиторіями в хмарі. Автоматично інтегрується з Bamboo та дозволяє автоматизувати збірку, тестування та розгортання коду, в залежності від конфігураційного файлу в репозиторії. Такі пайплайни та Docker дозволяють робити білди дуже швидко;
— Багато способів нотифікації. Bamboo-дошка виводить результати різних збірок та дозволяє налаштувати розсилки на пошту та в різні чати у випадку невдалої збірки, падіння тестів тощо;
— Різноманітні можливості простої інтеграції. Bamboo підтримує більшість основних технологічних стеків: CodeDeply, Docker, Maven, Git, SVN, Mercurial, Ant, AWS, Amazon S3 Buckets. Корисним є те, що система сама відслідковує оновлення в технологіях. Також є функція окремих дозволів на кожне оточення, що уможливлює легке масштабування;
— Документація та підтримка. Bamboo має чудову детальну документацію, а підтримку забезпечує Atlassian. Однак, спільнота Bamboo значно менша, ніж у Jenkins.

— Мало плагінів. Особливо порівняно з Jenkins та TeamCity;
— Складний перший досвід використання. Багато коментарів про те, що автоматизація розгортання вперше — нетривіальна задача, бо система не має інтуїтивних опцій та не дає розуміння, коли та як їх використовувати;
— Відсутність хмарного рішення;
— Платна система (тріал-версія має обмеження).

Висновок: гарний вибір, якщо потрібно інтегруватися з продуктами Atlassian.

4. GitLab CI/CD: система безперервної інтеграції в репозиторії

Ідея GitLab CI дуже проста: якщо створити .gitlab-ci.yml файл безпосередньо у репозиторії та налаштувати проєкт у GitLab так, щоб він мав Runner, тоді кожен merge або push буде запускати пайплайн.

Основні переваги: Основні недоліки:

— Зручна система з чудовою підтримкою Docker/Kubernetes;
— Система контролю версій та система безперервної інтеграції в одному інструменті;
— Легко налаштувати та масштабувати власний сервер збірок, тобто GitLab-Runner;
— Безкоштовна система з відкритим кодом;
— Паралельне виконання Jobs;
— Легко вирішувати конфлікти;
— Підтримка хмарного рішення і власного сервера;
— Код і Pipeline в одному місці. Зручне оформлення Pipeline.

— Артефакти треба визначати та завантажувати окремо у кожному випадку;
— Майже неможливо перевірити стан проєкту до того, як безпосередньо відбудеться злиття гілки.

Висновок: ідеальний вибір для роботи з Git та Docker-контейнерами та найпростішої інтеграції з системою контролю версій.

5. Azure DevOps: безперервна інтеграція для Microsoft-стеку

Azure DevOps — велика система, яка також інтегрує в собі все, що потрібно для створення програми: репозиторії для зберігання коду, збірка, тестування та розгортання на різних оточеннях, масштабування продукту за потреби. Система підтримує білд-агенти для Linux, Windows та macOS, має реалізацію пайплайнів.

Основні переваги: Основні недоліки:

— Зручність у використанні. Нові користувачі можуть працювати через графічний інтерфейс, зрозумілий та комфортний. Більш досвідченим сподобається можливість описувати інфраструктуру як код у вигляді YAML — файлів;
— Вбудовані функції розділяються по категоріях. Категорії визначають, навіщо потрібні ті чи інші завдання, наприклад, збірка, розгортання, обладнання тощо. Це дозволяє легко знайти все, що потрібно;
— Можливість групувати завдання. Завдання, зібрані в пайплайн, можна визначити як ще одне завдання: щось подібне до інкапсуляції;
— Наявність плагінів. Якщо чогось немає безпосередньо в системі, можливо, задачу допоможе вирішити плагін;
— Хостинг білд-агентів у Microsoft. Можна переглянути, які саме програми встановлені в агентах;
— Широкий вибір мов програмування, платформ та хмарних рішень. Розробка, тестування, збірка та розгортання Node.js, Python, Java, PHP, Ruby, C/C++, .Net, Android та iOS програм. Можливість паралельної роботи з Linux, macOS та Windows. Розгортання у хмарах Azure, AWS, GCP або локально;
— Необмежена кількість хвилин для збірки для всіх проєктів з відкритим кодом та до 10 паралельних Jobs на Linux, macOS та Windows;
— Підтримка хмарного рішення і власного сервера.

— Заскладна інтеграція з не-Microsoft стеком. Azure DevOps підтримує інтеграцію не лише з Microsoft-рішеннями, але це непроста задача;
— Пайплайни не підтримують умовних конструкцій, лише послідовності. Тож для складних випадків задача створення відповідної структури в системі безперервної інтеграції може бути неочевидною;
— Серед доступних плагінів на маркетплейсі є такі, що вже неактуальні;
— Висока ціна за користування сервісами. Оплата сервера та сервісу;
— Документація давно не змінювалася.

Висновок: вдале рішення для продуктів на Microsoft-стеку, одна точка входу, можливість все мати в одному місці.

Бонус: створення пайплайнів у різних системах безперервної інтеграції

Пайплайн — важливий елемент безперервної інтеграції, який є, по суті, послідовністю окремих кроків процесу збірки, тестування та розгортання системи (Job в термінах Jenkins). В тому чи іншому вигляді він наявний у всіх сучасних системах безперервної інтеграції.

Jenkins

Пайплайни в Jenkins — це власне послідовність збірок, тестування та розгортання, що відбувається між додаванням нового коду до системи контролю версій та системою, доступною для кінцевих користувачів. В цій системі можна створювати та зберігати пайплайни у вигляді коду згідно з принципом IaC — Infrastructure as a code (інфраструктура у вигляді коду). Ось маленькі приклади таких файлів з кодом для різних мов програмування:

1. Java. Jenkinsfile (Declarative Pipeline):

pipeline {
    agent { docker { image 'maven:3.3.3' } }
    stages {
        stage('build') {
            steps {
                sh 'mvn clean install'
            }
        }
    }
}

2. Node.js / JavaScript. Jenkinsfile (Declarative Pipeline):

pipeline {
    agent { docker { image 'node:14-alpine' } }
    stages {
        stage('build') {
            steps {
                sh 'npm build --prod'
            }
        }
stage('build Docker') {
            steps {
                sh 'docker build –t frontend:${BUILD_NUMBER} .'
            }
        }
stage('Deploy Docker') {
            steps {
                sh 'docker run –p 4200:4200 –restart=always –-name frontend –frontend:${BUILD_NUMBER}'
            }
        }
    }
}

Приклад візуалізації пайплайну

TeamCity

В цій системі пайплайни називаються Build Chains. Є простий візуальний редактор, який дозволяє їх створювати.

Приклад візуалізації та конфігурування пайплайну

Bamboo

Пайплайни в Bamboo називаються Flows. Є окремий плагін, який дозволяє візуалізувати їх у вигляді потокових діаграм. В цілому, ідея пайплайнів залишається аналогічною до інших систем безперервної інтеграції. Пайплайни створюються через інтерфейс.

Приклад візуалізації та конфігурування пайплайну


Конфігурація пайплайну:

Візуалізації пайплайну:

GitLab

Нижче — приклад .gitlab-ci.yml файлу, що реалізує пайплайн, якщо покласти його безпосередньо в репозиторій.

image: alpine

build:
  stage: build
  script: 
    - echo "building..."
    - echo "artifact from project:$CI_PROJECT_PATH, branch:$CI_COMMIT_BRANCH, job_url:$CI_JOB_URL" > artifact.txt
  artifacts:
    paths: [artifact.txt]
  rules:
    - if: "$CI_COMMIT_BRANCH == 'master'"

unit_tests:
  stage: test
  script: echo "running unit tests..."

integration_tests:
  stage: test
  script: echo "running integration tests..."

system_tests:
  stage: test
  trigger:
    project: gitlab-examples/system-tests
    branch: master
    strategy: depend
  variables:
    ARTIFACTS_JOB: build
    ARTIFACTS_FILE: artifact.txt
    UPSTREAM_COMMIT_BRANCH: $CI_COMMIT_BRANCH

deploy:
  stage: deploy
  script: echo "deploying app..."

metrics:
  stage: deploy
  trigger:
    project: gitlab-examples/metrics
    branch: master
  variables:
    PROJECT_URL: $CI_PROJECT_URL
    PROJECT_NAME: $CI_PROJECT_NAME
    COMMIT_SHA: $CI_COMMIT_SHA

Приклад візуалізації пайплайну

Azure DevOps

Приклад YAML — файла для визначення пайплайну як коду.

pool: 
   vmImage: ubuntu-latest
jobs:
- job: waitForValidation
  displayName: Wait for external validation  
  pool: server    
  timeoutInMinutes: 4320 # job times out in 3 days
  steps:   
   - task: ManualValidation@0
     timeoutInMinutes: 1440 # task times out in 1 day
     inputs:
         notifyUsers: |
            someone@example.com
         instructions: 'Please validate the build configuration and resume'
         onTimeout: 'resume'
- job: myPostValidationJob
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - bash: echo "Hello world"

Summary

Попрацювавши з усіма системами, які описані в статті, мені найбільше подобається GitLab, оскільки він не потребує купівлі чи інсталяції додаткових плагінів для роботи з певним хмарним провайдером, певною технологією тощо. Візуалізація пайплайнів в GitLab не є такою яскравою, як в інших СІ системах, проте її цілком вистачає для роботи:

Azure DevOps надає чудову візуалізацію пайплайнів, допомагаючи користувачу легко зрозуміти, що відбувається в тому чи іншому пайплайні. Також, пайплайни, як конструктор, можна збирати або описувати кодом:

Jenkins хоча і є однією з найпопулярніших СІ систем, має свої недоліки. У цій системі потрібно встановлювати безліч плагінів, щоб працювати з певною технологією, і це дуже незручно. У Bamboo, на відміну від Jenkins та GitLab, наразі ще слабо розвинені скриптовані пайплайни. Також мені не подобається візуалізація пайплайнів у Bamboo та TeamCity.

На завершення

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

👍НравитсяПонравилось9
В избранноеВ избранном5
Подписаться на автора
LinkedIn

Похожие статьи

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Основная проблема дженкинса — поддержка плагинов в актуальном виде. Или ты пользуешься почти без них, или через пару лет использования дженкинса у тебя полюбому будут проблемы с какими-то устаревшими.
Вдобавок визуальная часть дженкинса конечно устарела, и в обозримом будущем я не вижу как можно сделать удачное решение для интерфейса в продукте с тучей кастомных плагинов.
С другой стороны, дженкинс абсолютно интуитивно понятный в поддержке продукт, бесплатный и удобный для максимальной гибкости.

Тимсити — наверное лучший с точки зрения визуализации всего. Кастомные табы творят чудеса для любых идей. Один раз настроенный профессионалом, легко может поддерживаться джунами. Жаль, что дорогой.

gitlab/github — это то, куда вообще стремится мир пайплайнов. Упрощение всего этого дела, перевод всей кастомизации с уровня CI на уровень сборщиков и контейнеров. Сложно сказать насколько это плохо или хорошо — это выгодно для самого процесса, поэтому скорее всего все там будем.

GitHub Actions, Bitbucket Pipelines — если вам их хватает то это просто прекрасно. Для многих простых проектов этого за глаза.

Добровольно заводить Jenkins в 2021 году я бы очень сильно подумал.
Я видимо старый и ленивый но мне кажеться что если нужно что то большее чем пайплайны\екшены — стоит смотреть на то что бы жить на штатных средствах вашего клауда. Просто для уменшения боли

Главная проблема jenkinsa — он морально устарел много лет назади очень плохо работает в клауде. О чем на интернете лежит большая статья создателя дженкинса. Еще не написали про AWS codebuild./codedeploy.

Джернкінс — класичний найс.
Github Actions — супер найс
Амазон Пайплайнс — супер найс
Бадді — будьласочка якщо будете прохохоити поряд — проходьте далі та не зупиняйтесь.

Про Гітхаб ані слова

И ни слова про то, что тот же Azure можно использовать для сборки iOS и MacOS проектов, что на yml можно забить, а писать весь код в скриптах Fastlane, что доступна бесплатная версия ограниченная 1 параллельно исполняемой джобой

Висновок: кожна система на любітєля. Усюди можна робити все.

Очікував побачити в статті CircleCI, шкода, що нема(
А загалом дякую!

а воно вже вміє реагувати на PR? здається, що ні.

І на коміт, і на ПР. Взагалі дуже хороша CI на сьогодні.

— Заскладна інтеграція з не-Microsoft стеком. Azure DevOps підтримує інтеграцію не лише з Microsoft-рішеннями, але це непроста задача;

Можете привести пример, в чём сложность интеграции с каким-либо не-Microsoft стеком? Сколько его юзал, не замечал каких-то сложностей. Хотя, может то у меня так, а у других иначе.

Так-же и про Дженкинс:

— Документації не завжди достатньо. Певні задачі (наприклад, переробити фрістайл джоби на скриптові пайплайни) потребують часу;
— Застарілий інтерфейс. Тут не завжди виконуються сучасні принципи дизайну. Піксельні іконки, скупчення елементів інтерфейсу, відсутність автоматичного оновлення в деяких випадках — все це виглядає не дуже сучасно;

Весьма спорно. Тем более, если работать постоянно с консолью, то пункт про устаревший интерфейс — вообще смешно.
Для примера — CentOS — один из самых популярных дистрибутивов для серверов, многие основные утилиты которого не меняются десятилетиями. Да, не по-хипстерски и не попсово, но, по некой причине — стабильность — не всегда минус. Тоже самое и с интерфейсом Дженкинса.

Насчёт документации — львинная доля функционала Дженкинса для конкретных задач, вынесена в плагины. Ещё не встречал ситуации, чтобы я не смог найти нужной мне информации в документациях плагинов. Может у вас неправильный подход к поиску информации в случае с Дженкинсом?

GitLab CI/CD: система безперервної інтеграції в репозиторії
Майже неможливо перевірити стан проєкту до того, як безпосередньо відбудеться злиття гілки.

Чого б це раптом? docs.gitlab.com/...​lines_for_merged_results

„With pipelines for merged results, the pipeline runs as if the changes from the source branch have already been merged into the target branch. The commit shown for the pipeline does not exist on the source or target branches but represents the combined target and source branches.”

Подписаться на комментарии