Что такое job и какие типы бывают
Job (он же item, он же "проект") в Jenkins - это единица работы. Внутри неё описано, что собирать, откуда брать код, какие шаги выполнять и что делать с результатом. Когда ты слышишь "у нас 300 jenkins jobs" - речь именно про эти настроенные единицы. Тип job определяет, как ты её описываешь и насколько она умеет жить сама.
Базовый набор типов, который ты увидишь на свежем Jenkins LTS (линейка 2.5xx.x, на 2026 год это семейство 2.516+ на Java 17/21):
- Freestyle project - классический кликабельный проект. Всё через веб-форму: галочки, текстовые поля, выпадающие списки.
- Pipeline - проект на основе скрипта-конвейера (Jenkinsfile), описанного кодом.
- Multibranch Pipeline - конвейер, который сам разворачивается на каждую ветку и pull request с Jenkinsfile.
- Folder - не сборка, а папка-контейнер для группировки других jobs.
- Organization Folder (GitHub Organization, Bitbucket, GitLab Group, Gitea) - сканирует целую организацию и сам плодит Multibranch-проекты на каждый репозиторий.
Jenkins freestyle: наследие, которое всё ещё живо
Jenkins freestyle - самый старый формат. Ты открываешь форму, выбираешь источник кода, добавляешь шаги сборки (Execute shell, Invoke Maven), настраиваешь триггеры и post-build действия мышкой. Никакого кода - всё кликается.
Звучит дружелюбно, и для пятиминутной задачи это правда удобно. Но у freestyle есть фундаментальные проблемы, из-за которых сообщество давно сдвинулось в сторону Pipeline:
- Конфигурация не в Git. Настройки живут в config.xml внутри Jenkins. Нет ревью, нет истории изменений рядом с кодом, нет отката через pull request.
- Хрупкость. Сложный freestyle - это десятки галочек и плагинов. Воспроизвести его на другом контроллере или после миграции - боль.
- Слабая логика. Условия, циклы, параллельные стадии, ручные подтверждения - всё это либо костыли через плагины, либо вообще никак.
Pipeline: конвейер как код
Тип Pipeline - это переход от кликов к коду. Логика сборки описана в Jenkinsfile, который лежит в репозитории рядом с приложением. Стандарт 2026 года - declarative pipeline: читаемый, со строгой структурой и понятными ошибками. Scripted (полный Groovy) держим в уме для случаев, где нужна настоящая динамика.
Минимальный, но рабочий declarative Jenkinsfile:
Код: Выделить всё
pipeline {
agent any
options {
timeout(time: 30, unit: 'MINUTES')
disableConcurrentBuilds()
}
stages {
stage('Build') {
steps {
sh 'mvn -B -DskipTests clean package'
}
}
stage('Test') {
steps {
sh 'mvn -B test'
}
post {
always {
junit 'target/surefire-reports/*.xml'
}
}
}
stage('Deploy') {
when {
branch 'main'
}
steps {
sh './deploy.sh staging'
}
}
}
post {
failure {
echo 'Сборка упала, разбираемся'
}
}
}
Multibranch pipeline: то, что нужно большинству
Вот здесь и происходит главный сдвиг. Multibranch pipeline - это jenkins проект, который ты настраиваешь один раз, указываешь ему репозиторий, а дальше он сам сканирует ветки и pull requests. Нашёл в ветке Jenkinsfile - создал для неё под-job и начал собирать. Ветку удалили - соответствующий job сам убирается (по умолчанию через настраиваемый период хранения).
Что это даёт на практике:
- Ноль ручной работы на ветку. Завёл feature/login - через минуту-другую (или сразу, если настроен вебхук) она уже собирается своим конвейером.
- Сборка pull request. PR проверяется до мёржа, статус летит обратно в GitHub/GitLab/Bitbucket. Сломанный код не доезжает до main.
- Разные Jenkinsfile в разных ветках. В main - полный пайплайн с деплоем, в feature - только сборка и тесты. Это просто разные файлы в разных ветках, никакой магии.
Сам Jenkinsfile для Multibranch выглядит так же, как для обычного Pipeline. Магия не в файле, а в директивах вроде when и в переменной BRANCH_NAME, которая подсказывает, в какой ветке мы сейчас:
Код: Выделить всё
pipeline {
agent any
stages {
stage('Build & Test') {
steps {
sh 'make build test'
}
}
stage('Deploy to prod') {
when { branch 'main' }
steps {
sh 'make deploy ENV=production'
}
}
stage('Preview env for PR') {
when { changeRequest() }
steps {
echo "Поднимаю preview для PR #${env.CHANGE_ID}"
sh './preview.sh up'
}
}
}
}
Folder и Organization: масштаб на десятки репозиториев
Когда репозиториев становится много, всплывают два организационных типа.
Folder - это просто папка. Сборки в ней не делаются, она группирует другие jobs: по командам, по продуктам, по окружениям. Внутри папки можно задать свои права доступа, свои переменные, свой набор агентов. Чисто наведение порядка в большом Jenkins.
Organization Folder (GitHub Organization, Bitbucket Team, GitLab Group, Gitea) - это Multibranch, поднятый на уровень выше. Ты указываешь не репозиторий, а целую организацию и креденшелы. Jenkins сканирует все репозитории, и для каждого, где есть ветка с Jenkinsfile, автоматически создаёт Multibranch Pipeline. Появился новый репозиторий с Jenkinsfile - сам появился и job. Это тот случай, когда CI настраивается практически без участия админа: разработчик кладёт Jenkinsfile в корень - и его проект уже в конвейере.
Связь типов по нарастанию автоматизации:
- Freestyle / Pipeline - один job на одну задачу или ветку.
- Multibranch Pipeline - один job на репозиторий, ветки и PR сами.
- Organization Folder - один job на организацию, репозитории сами.
Типичные грабли
- Начинать с Freestyle "потому что проще". Через полгода это десятки несогласованных jobs без истории в Git. Стартуй с Pipeline или Multibranch.
- Multibranch без вебхука. Ждёшь сборку новой ветки, а её нет - пересканирование по таймеру ещё не наступило. Настрой вебхук от Git-сервера.
- Забыть про права в Organization Folder. Сканирование всей организации тянет в Jenkins всё подряд. Ограничивай через фильтры репозиториев и креденшелы с минимальными правами.
- Тяжёлые Jenkinsfile в каждой ветке. При сканировании Jenkins прогоняет файл из каждой ветки. Логику выноси в Shared Library, в Jenkinsfile держи только оркестрацию.
Руками, чтобы осело:
- Создай Freestyle с одним шагом Execute shell (echo plus uname -a). Запусти, глянь, где лежит его config.xml.
- Создай Pipeline-проект, вставь declarative Jenkinsfile из урока, прогони.
- Заведи Multibranch Pipeline на свой тестовый репозиторий с двумя ветками (main и feature), в каждой - свой Jenkinsfile. Проверь, что Jenkins создал по job на ветку.
- Открой pull request из feature в main и убедись, что появился job на PR (changeRequest()).
- Чем конфигурация Freestyle принципиально хуже Pipeline с точки зрения хранения и ревью?
- Что именно автоматически делает Multibranch Pipeline при появлении новой ветки с Jenkinsfile?
- В чём разница между Multibranch Pipeline и Organization Folder по уровню охвата?
- Почему без вебхука новая ветка может собраться не сразу, и как это лечится?
Freestyle - наследие для разовых задач. Pipeline - конвейер как код, база современного Jenkins. Multibranch Pipeline - выбор по умолчанию для нормального репозитория с ветками и PR: настроил раз, дальше всё само. Organization Folder - тот же принцип на масштаб целой организации. Запомни лестницу автоматизации - и больше не будешь плодить сотни ручных jobs там, где хватит одного правильно выбранного типа.
