Skip to content

Jenkins.md

Latest commit

 

History

History
89 lines (64 loc) · 6.95 KB

Jenkins.md

File metadata and controls

89 lines (64 loc) · 6.95 KB
Raw

← Оглавление

Jenkins

Ветеран CI/CD: свой сервер автоматизации, который сам соберёт, протестирует и выкатит — под тысячи плагинов

Jenkins — открытый сервер автоматизации для CI/CD, написанный на Java. Один из старейших и самых распространённых инструментов: по событию (пуш, расписание) он сам прогоняет сборку, тесты и деплой. Ключевое отличие от GitHub Actions / GitLab CI — Jenkins self-hosted: ты сам разворачиваешь и обслуживаешь сервер, зато полный контроль и гигантская экосистема плагинов.

Место в CI/CD

Принципы CI/CD (частая интеграция, автосборка/тесты, автодеплой) — в отдельной заметке. Jenkins — один из движков, который эти пайплайны исполняет. Альтернативы — GitHub Actions, GitLab CI, TeamCity; идея та же, разнятся хостинг и конфигурация.

Как устроено

  • Controller (контроллер) — «мозг»: хранит конфигурацию, планирует задачи, показывает веб-интерфейс.
  • Agents (агенты, ноды) — рабочие машины, где реально выполняются задачи. Так нагрузка распределяется, а сборки идут в нужных окружениях.
  • Job / Pipeline — определённый процесс (собрать → протестировать → выкатить).
  • Плагины — почти всё в Jenkins делается плагинами (Git, Docker, Kubernetes, Slack, отчёты). Их тысячи — сила и одновременно боль Jenkins.

Pipeline as Code — Jenkinsfile

Современный Jenkins описывает пайплайн кодом в файле Jenkinsfile в репозитории (а не кликами в GUI, как старые «freestyle»-задачи). Два стиля: декларативный (структурированный, рекомендуемый) и скриптовый (полный Groovy).

pipeline {
  agent any                          // на каком агенте выполнять
  stages {
    stage('Build') {
      steps { sh 'pip install -r requirements.txt' }
    }
    stage('Test') {
      steps { sh 'pytest' }
    }
    stage('Deploy') {
      when { branch 'main' }         // только для main
      steps { sh 'docker build -t myapp . && docker push myapp' }
    }
  }
  post {
    failure { echo 'Сборка упала' }  // действия по итогу (успех/провал)
  }
}
  • stages / stage — этапы пайплайна; steps — команды внутри этапа.
  • agent — где выполнять (любой агент, конкретный, в контейнере).
  • post — что сделать по завершении (уведомить, очистить) в зависимости от результата.

Триггеры

  • По пушу — вебхук из Git-репозитория запускает пайплайн (основной режим CI).
  • По расписанию — cron-выражение (ночные сборки, регресс).
  • Вручную — кнопкой (обычно для деплоя в прод).

Jenkins против GitHub Actions / GitLab CI

Jenkins GitHub Actions / GitLab CI
Хостинг self-hosted (сам ставишь и обслуживаешь) встроен в хостинг репозитория (SaaS)
Конфигурация Jenkinsfile (Groovy) + плагины YAML в репозитории
Гибкость очень высокая (плагины подо всё) проще, но привязка к платформе
Обслуживание сервер, обновления, плагины — на тебе почти нулевое
Когда сложные/легаси-пайплайны, свой контур новый проект на GitHub/GitLab

Ловушки

Плагиновый ад. Мощь Jenkins — в плагинах, но их несовместимость и обновления — постоянный источник поломок. Держи набор плагинов минимальным и следи за версиями.

Обслуживание на тебе. Self-hosted — значит сам отвечаешь за доступность, бэкапы, безопасность и обновления сервера. Для простого проекта на GitHub встроенные Actions обычно дешевле по усилиям.

Секреты. Не хардкодь пароли/токены в Jenkinsfile — используй Credentials-хранилище Jenkins (Веб-безопасность).

GUI-задачи вместо кода. Старые «freestyle»-задачи, настроенные кликами, не версионируются и не ревьюятся. Пиши пайплайн в Jenkinsfile под гитом.

Связи

Источники