В этом вводном уроке разберёмся: что такое Jenkins простыми словами, зачем вообще нужен подход CI/CD, что Jenkins реально делает под капотом, откуда он взялся и какое место занимает в 2026 году рядом с GitLab CI и GitHub Actions. Кода тут будет немного - это концептуальная глава, фундамент под остальной курс. Но один маленький Jenkinsfile в конце мы всё-таки посмотрим, чтобы ты увидел, к чему мы идём.
Что такое Jenkins простыми словами
Если совсем коротко, Jenkins - это open-source сервер автоматизации, написанный на Java. Он бесплатный, ставится у тебя (on-premise или в облаке) и умеет по сигналу запускать любую последовательность действий: собрать проект, прогнать тесты, упаковать артефакт, выкатить на сервер, отправить уведомление в чат. Ты описываешь, что должно произойти, а Jenkins честно это выполняет - каждый раз одинаково, без человеческого фактора.
Когда спрашивают, что такое jenkins, проще всего представить его как очень дисциплинированного робота-сборщика. Ему всё равно, пятница сейчас или ночь, устал он или нет. Пришёл новый коммит в git - робот проснулся, собрал, проверил, доложил о результате. В этом и есть суть: Jenkins это про то, чтобы вынуть рутину из рук людей и отдать машине.
Технически Jenkins состоит из двух типов узлов. Контроллер (controller) - это мозг: веб-интерфейс, планировщик задач, хранилище конфигурации и истории сборок. Агенты (agent) - это руки: отдельные машины или контейнеры, на которых реально выполняется работа. Раньше эти роли называли master и slave, но это устаревшая терминология - сейчас правильно говорить контроллер и агент. Маленький проект может жить на одном контроллере, большой - раскидывает нагрузку на десятки эфемерных агентов, поднимающихся в Kubernetes на время сборки. До такой схемы мы дойдём в отдельном уроке курса.
Зачем нужен CI/CD и при чём тут jenkins ci cd
CI/CD - это две связанные практики. Расшифруем без воды.
CI (Continuous Integration, непрерывная интеграция) - это привычка вливать изменения в общую ветку часто, маленькими порциями, и на каждое вливание автоматически собирать проект и гонять тесты. Идея в том, что чем мельче и чаще интеграции, тем раньше ты ловишь конфликт или сломанный тест. Не раз в месяц перед релизом, когда сто коммитов схлестнулись и непонятно, чей именно сломал сборку, а сразу - на конкретном коммите.
CD прячет за собой сразу два понятия. Continuous Delivery (непрерывная доставка) - это когда любая прошедшая проверки сборка в любой момент готова к выкатке, а нажатие кнопки деплоя остаётся за человеком. Continuous Deployment (непрерывное развёртывание) идёт дальше: успешная сборка уезжает на прод вообще без ручного вмешательства.
Зачем всё это? Ради быстрой обратной связи. Сломал что-то - узнал об этом через пять минут от Jenkins, а не через две недели от пользователя. Связка ci cd jenkins превращает релиз из стрессового события в скучную рутину, которая случается по десять раз в день и никого не пугает. А ещё это воспроизводимость: сборка идёт по описанному в коде сценарию, одинаково у всех, и ты всегда знаешь, что именно лежит на проде.
Что именно делает Jenkins: триггеры, сборка, тесты, деплой
Рабочий цикл устроен предсказуемо. Сначала срабатывает триггер - событие, запускающее работу. Чаще всего это push в репозиторий: git-хостинг дёргает webhook, и Jenkins стартует. Бывают триггеры по расписанию (cron), по завершению другой задачи или просто по кнопке вручную.
Дальше Jenkins выполняет пайплайн - описанную тобой цепочку шагов. Типичный набор:
- забрать свежий код из git (checkout);
- собрать проект (компиляция, сборка образа, упаковка артефакта);
- прогнать тесты - юнит, интеграционные, линтеры;
- опубликовать артефакт в реестр или хранилище;
- выкатить на нужное окружение - stage, потом prod;
- сообщить результат команде в Slack, Telegram или почтой.
Код: Выделить всё
pipeline {
agent any
stages {
stage('Checkout') {
steps {
checkout scm
}
}
stage('Build') {
steps {
sh './gradlew clean build -x test'
}
}
stage('Test') {
steps {
sh './gradlew test'
}
post {
always {
junit 'build/test-results/test/*.xml'
}
}
}
stage('Deploy') {
when {
branch 'main'
}
steps {
sh './deploy.sh staging'
}
}
}
post {
failure {
echo 'Сборка упала - чиним'
}
}
}
Краткая история: Hudson, Jenkins, Jenkins 2
Чтобы понимать, почему пайплайны - это так важно, нужна щепотка истории. Проект родился в 2004 году под именем Hudson внутри Sun Microsystems. После того как Oracle поглотила Sun, сообщество разругалось с новым владельцем из-за прав на торговую марку и в 2011 году форкнуло проект под именем Jenkins. Hudson тихо умер, Jenkins расцвёл.
До 2016 года Jenkins был кликательным: задачи (job) настраивались мышкой через веб-формы, а сложную логику костыляли цепочками отдельных job. Это плохо версионировалось и быстро превращалось в хаос. Переломным стал Jenkins 2 (2016): он сделал пайплайны как код первоклассной возможностью. Появился Jenkinsfile, появился declarative-синтаксис чуть позже - и центр тяжести сместился с мышки на код в репозитории. Именно к этой главной фиче Jenkins 2 мы и будем возвращаться весь курс.
Кстати про Blue Ocean - графический редактор пайплайнов из той же эпохи. В книгах 2018-2019 годов его расхваливают, но в 2026 строить на нём ничего не стоит: проект давно в режиме поддержки, новых фич не получает, только редкие заплатки по безопасности. Считай его наследием. Современный UI Jenkins вырос и без него.
Место Jenkins в 2026: стандарт энтерпрайза рядом с GitLab CI и GitHub Actions
Расставим точки честно, без фанатизма. За годы рядом с Jenkins выросли сильные конкуренты. GitHub Actions - дефолт для всего, что живёт на GitHub, особенно для стартапов и open-source. GitLab CI - встроенный CI прямо в GitLab, очень удобный, если вся разработка уже там, и быстро растущий в энтерпрайзе. Оба - YAML-конфиг в репозитории, минимум возни с инфраструктурой.
При этом Jenkins никуда не делся. По свежим данным 2026 года он остаётся костяком CI/CD примерно в 80% компаний из Fortune 500 - там, где сложные пайплайны, строгие требования к данным и многолетние вложения в инфраструктуру. Да, его доля среди новых проектов снижается год к году, и нередко в одной компании уживаются оба подхода: новые микросервисы на GitHub Actions, тяжёлые легаси-конвейеры на Jenkins. Главные козыри Jenkins - полный контроль (он крутится на твоём железе, данные не уходят наружу), огромная экосистема плагинов под что угодно и гибкость, которой не всегда хватает облачным конкурентам.
Из важного для актуальности: современный Jenkins требует свежей Java. Линия LTS начала 2026 года (ветка 2.541.x) работает на Java 17, при этом это последний LTS с поддержкой Java 11, а еженедельные сборки уже подняли планку до Java 21. Так что разворачивая Jenkins сегодня, ставь Java 17 как минимум, а лучше сразу Java 21 - дальше требования только растут. И ещё две вещи из 2026, которых нет в книге 2018 года и которые мы разберём отдельно: JCasC (Configuration as Code - настройка всего Jenkins одним yaml-файлом, без кликанья мышкой) и эфемерные агенты в Kubernetes, поднимающиеся под каждую сборку и исчезающие после неё.
Мини-лаба: что повторить руками
Кода тут пока минимум, лаба - на размышление и подготовку:
- Возьми последний релиз своего проекта (или любого знакомого) и честно выпиши по шагам, что делается руками: собрать, протестировать, выложить. Это твой будущий пайплайн.
- Отметь, на каком из шагов чаще всего что-то ломается или забывается. Эти места CI/CD закроет первыми.
- Зайди на jenkins.io, найди раздел загрузок и посмотри, какая сейчас актуальная LTS-версия и какая Java ей нужна. Сверь с тем, что написано выше.
- Открой Jenkinsfile из примера и для себя проговори словами, что делает каждый stage. Если получилось - базовую идею declarative pipeline ты уже ухватил.
- Чем отличается Continuous Integration от Continuous Delivery и Continuous Deployment?
- Какие два типа узлов есть в архитектуре Jenkins и за что отвечает каждый? Как они назывались раньше?
- Что такое Jenkinsfile и почему подход pipeline as code лучше настройки задач мышкой?
- Почему в 2026 году Jenkins всё ещё силён в энтерпрайзе, хотя GitHub Actions и GitLab CI отъедают долю?
Jenkins - это бесплатный сервер автоматизации на Java, который берёт на себя сборку, тесты и доставку кода, убирая ручную рутину и давая команде быструю обратную связь. CI/CD - это практика частых интеграций и готовых к выкатке сборок, а Jenkins - один из главных движков для неё. Ключевая фишка современного Jenkins 2 - пайплайны как код в файле Jenkinsfile, и именно их мы будем подробно собирать дальше. В следующем уроке ставим Jenkins и запускаем первую сборку своими руками.
