Что такое Jenkins и почему он до сих пор жив
Если коротко: jenkins - это сервер автоматизации с открытым кодом, который умеет запускать твои сборки, тесты и деплои по триггеру (коммит, расписание, кнопка, вебхук). Написан на Java, ставится на свой сервер, работает где угодно - хоть в облаке, хоть в подвале без интернета. Это и есть его главная фишка: ты хозяин инфраструктуры целиком.
Архитектура простая. Есть контроллер (controller) - мозг системы: хранит конфигурацию, показывает веб-интерфейс, раздаёт задания. И есть агенты (agent) - рабочие лошадки, которые реально выполняют сборку. Раньше эти штуки звали master и slave, но термины давно поменяли на нейтральные controller и agent - встретишь старое слово в чужом гайде, знай, что это одно и то же.
Главная боль и главная сила Jenkins - это плагины. Их около 1800+ штук. Хочешь интеграцию с Docker - плагин. С Kubernetes - плагин. С Slack, Jira, SonarQube, любым облаком - плагин. Из коробки Jenkins умеет немного, всё остальное докручивается. Звучит как мечта, но есть обратная сторона: плагины пишут разные люди, качество скачет, а при обновлении что-то отваливается. Классика жанра - обновил ядро, а половина плагинов несовместима. Поэтому реальный Jenkins-инженер половину времени не пишет пайплайны, а занимается совместимостью версий. Это та самая "плагинная боль", о которой все говорят.
Актуальное состояние на 2026: версии и Java
Книги по Jenkins 2018-2019 годов до сих пор полезны по идеям, но цифры там мёртвые. Давай сверим по факту на 2026.
Jenkins живёт двумя ветками. Weekly - еженедельные релизы со свежими фичами и свежими багами, для энтузиастов. LTS (Long-Term Support) - стабильная ветка, которую обновляют раз в 12 недель и патчат по безопасности. На проде берёшь только LTS, без вариантов.
Актуальная LTS на середину 2026 - это линейка 2.541.x (релиз 2.541.1 вышел 21 января 2026). И вот важный момент про Java, который ломает много кому установки:
- Линейка 2.541.x - последняя LTS, где ещё работает Java 11. Дальше её выпиливают.
- Поддержка Java 17 заканчивается в марте 2026, дальше базовая планка - Java 21.
- Свежие weekly-релизы (2.543 и выше) уже требуют Java 21 как минимум.
- Ближайшая новая LTS (апрель 2026) дропает Java 17 и встаёт на Java 21.
Код: Выделить всё
java -version
# openjdk version "21.0.x" 2026-xx-xx LTS
# OpenJDK Runtime Environment Temurin-21...
# и версию самого Jenkins из CLI
curl -s http://localhost:8080/api/json | python3 -c "import sys,json;print(json.load(sys.stdin).get('version','?'))"
Pipeline as Code - ответ Jenkins на современность
Главная причина, почему Jenkins не умер, - он вовремя ушёл от кликанья мышкой к коду. Твой конвейер описывается текстом в файле Jenkinsfile, который лежит рядом с кодом в репозитории. Это и есть Pipeline as Code: пайплайн версионируется, ревьюится в pull request и воспроизводится. По умолчанию в 2026 пишут declarative pipeline - декларативный синтаксис, читаемый и предсказуемый. Scripted (на чистом Groovy) берут только там, где нужна динамика и сложная логика.
Вот живой, рабочий минимальный Jenkinsfile в декларативном стиле:
Код: Выделить всё
pipeline {
agent any
options {
timeout(time: 20, unit: 'MINUTES')
disableConcurrentBuilds()
}
stages {
stage('Build') {
steps {
sh 'echo "Собираем проект"'
sh './gradlew clean build -x test'
}
}
stage('Test') {
steps {
sh './gradlew test'
}
post {
always {
junit 'build/test-results/**/*.xml'
}
}
}
stage('Deploy') {
when { branch 'main' }
steps {
sh './deploy.sh production'
}
}
}
post {
failure {
echo 'Сборка упала - разбираемся'
}
}
}
И раз уж мы про современность - в 2026 нормальный Jenkins настраивается не руками через UI, а через JCasC (Configuration as Code, плагин configuration-as-code). Вся конфигурация контроллера - в одном YAML-файле:
Код: Выделить всё
jenkins:
systemMessage: "Cyberlake CI controller, управляется через JCasC"
numExecutors: 0
mode: EXCLUSIVE
authorizationStrategy:
loggedInUsersCanDoAnything:
allowAnonymousRead: false
unclassified:
location:
url: "https://ci.example.ru/"
tool:
jdk:
installations:
- name: "jdk21"
home: "/opt/java/temurin-21"
Код: Выделить всё
pipeline {
agent {
kubernetes {
yaml '''
apiVersion: v1
kind: Pod
spec:
containers:
- name: gradle
image: gradle:8-jdk21
command: ['sleep']
args: ['infinity']
'''
}
}
stages {
stage('Build') {
steps {
container('gradle') {
sh 'gradle build'
}
}
}
}
}
Честное сравнение CI: jenkins vs gitlab и github actions
Теперь сравнение ci по-взрослому, без фанатизма. По грубой оценке рынка на 2026 расклад примерно такой: GitHub Actions около трети проектов, Jenkins около четверти, GitLab CI ближе к пятой части. Все три - живые и востребованные, выбор зависит от контекста.
Jenkins. Максимальная гибкость, 1800+ плагинов, полный self-hosted, работает в air-gapped (без интернета) средах, тянет любые источники кода и любую экзотику. Минусы: ты сам себе админ, обновления и совместимость плагинов - твоя головная боль, порог входа выше. Это легаси-груз, но он же даёт свободу.
GitLab CI. Встроен прямо в GitLab, пайплайн описывается в .gitlab-ci.yml, всё в одной платформе - репозиторий, CI, реестр образов, сканеры безопасности (SAST, DAST). Раннеры можно поднять свои. Удобно, когда хочешь один инструмент на всё и встроенный комплаенс.
GitHub Actions. Marketplace на 20000+ готовых экшенов, запускается за минуты, облачные раннеры из коробки (есть и self-hosted). Идеален, если код уже на GitHub и стартуешь с нуля. Минус - сильная привязка к экосистеме GitHub.
Когда jenkins vs gitlab выигрывает Jenkins: закрытый контур без интернета, код размазан по разным VCS (часть в SVN, часть в Git), сложная логика пайплайна, которую YAML выражает уродливо, и есть выделенная DevOps-команда. Когда брать GitLab или jenkins github actions решается в пользу Actions: новый проект, маленькая команда, нет желания админить сервер, всё уже живёт на GitHub или GitLab. Смотри на TCO трезво: для небольшой команды Jenkins - самый дорогой по совокупной стоимости вариант именно из-за обслуживания, а его кастомизация окупается только когда тебе реально нужно то, чего облачные CI не умеют.
Типичные грабли
- Поставил Jenkins на старую Java (8 или 11) "по гайду из интернета" - в 2026 он либо не стартует, либо это тупик без обновлений. Сразу Java 21.
- Взял weekly-ветку на прод ради свежей фичи и ловишь баги каждую неделю. Прод - только LTS.
- Натыкал кучу плагинов "на всякий случай" - получил несовместимость при первом же обновлении ядра. Ставь только то, что используешь, и обновляй осознанно.
- Настроил всё руками через UI и не сохранил нигде. Упала машина - конфиг потерян. Лечится через JCasC и Jenkinsfile в репозитории.
- Строишь интерфейс и обучение команды вокруг Blue Ocean. Он заброшен, ты строишь на песке.
Руками, без спешки:
- Подними Jenkins LTS в Docker: jenkins/jenkins:lts на базе Java 21. Зайди в UI, посмотри версию ядра и версию Java в System Information.
- Создай Pipeline-джобу, вставь минимальный declarative Jenkinsfile из урока со стадиями Build и Test, запусти, посмотри на граф стадий.
- Открой раздел плагинов, найди configuration-as-code и kubernetes - просто прочитай их описания, чтобы понимать, что это и зачем.
- Для себя выпиши в три колонки Jenkins / GitLab CI / GitHub Actions по своему текущему проекту: где код, нужен ли закрытый контур, есть ли кому админить. Сделай вывод, что подошло бы тебе.
- Чем ветка LTS отличается от weekly и какую ты возьмёшь на прод в 2026?
- Какая минимальная версия Java актуальна для свежего Jenkins в 2026 и почему не стоит ставить на Java 11/17?
- Назови две ситуации, где Jenkins объективно лучше GitHub Actions, и две, где наоборот.
- Что такое Pipeline as Code и какие проблемы старого Jenkins он решает?
Jenkins в 2026 - не музейный экспонат, а зрелый, гибкий self-hosted инструмент на актуальной LTS (2.541.x) и Java 21, с Pipeline as Code, JCasC и эфемерными агентами в Kubernetes. Его сила - свобода и 1800+ плагинов, его боль - обслуживание и совместимость. GitHub Actions и GitLab CI проще и быстрее на старте, но Jenkins незаменим там, где нужен полный контроль, закрытый контур и нестандартная логика. Дальше в курсе мы соберём всё это руками - от первого Jenkinsfile до продакшен-конвейера.
