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

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Мене звуть Ганна Каплун, я 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. Скоріш за все, ця система перша спадатиме вам на думку, коли йдеться про безперервну інтеграцію.

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

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

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

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

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

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

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

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

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

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

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

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

Висновок: вдале рішення для продуктів на 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: |
            [email protected]
         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.

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

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