Jenkins

Контроллер — это мозг: он обслуживает веб-интерфейс, хранит конфигурацию, credentials и историю сборок, планирует сборки и запускает плагины. Агенты — это рабочие, которые подключаются к контроллеру и реально выполняют шаги сборки. У агента несколько executor-ов, каждый может выполнять одну сборку. Сборки выбирают агентов по метке, поэтому job, которому нужен Docker, просит docker, а не имя хоста. Сам контроллер не должен запускать сборки, потому что скрипты сборки — это код из репозиториев, и он может прочитать секреты контроллера или повредить его конфигурацию. Современные установки используют эфемерных агентов — под Kubernetes или облачную VM на каждую сборку, — которые каждый раз чистые и масштабируются по спросу.

У declarative pipeline фиксированная структура: pipeline, agent, stages, steps, post, when, options. Jenkins может провалидировать его до запуска, представления в стиле Blue Ocean его понимают, и всей команде его проще читать. Scripted pipeline — это обычный Groovy внутри блоков node: максимум гибкости, но его легко превратить в нечитаемую программу с тонкими проблемами CPS-сериализации. Мой выбор по умолчанию — Declarative для каждого Jenkinsfile и блок script только для небольшой неизбежной логики. Когда нужна настоящая логика, ей место в Shared Library с тестами, которую вызывает короткий Declarative Jenkinsfile, а не во встроенном Groovy в каждом репозитории.

Храните их в хранилище credentials Jenkins с областью видимости папки той команды, которой они нужны, или получайте из внешнего менеджера вроде Vault через плагин. В пайплайнах привязывайте их только там, где нужно, через withCredentials или credentials() в блоке environment — это заодно маскирует их в логах. Используйте sh-строки в одинарных кавычках, чтобы переменную раскрывал shell, а не Groovy; Jenkins даже предупреждает о небезопасной интерполяции. Никогда не выводите секреты через echo и не передавайте их аргументами команд, где они видны в списке процессов. Ограничьте, кто может настраивать job-ы: любой, кто может редактировать пайплайн, может напечатать доступный ему credential. И периодически проводите аудит использования credentials.

Относитесь к нему как к любому production-сервису. Используйте LTS и обновляйтесь по графику, репетируя на staging-контроллере, восстановленном из свежего бэкапа. Плагинов должно быть мало, и они должны быть актуальными; неиспользуемые удаляйте. Описывайте контроллер через Configuration as Code в Git, чтобы его можно было пересобрать; job-ы берутся из Jenkinsfile через Multibranch или organization folders, а не из UI. Бэкапьте jenkins_home или хотя бы те части, которые нельзя воспроизвести из Git. Используйте эфемерных агентов из образов, собранных в CI, чтобы инструменты агентов тоже были версионированы. Мониторьте место на диске, длину очереди и загрузку executor-ов и удаляйте старые сборки и артефакты через logRotator, чтобы диск не заполнился незаметно.

Multibranch Pipeline — это тип job-а, который указывает на репозиторий и автоматически создаёт под-job для каждой ветки, а при желании и каждого pull request-а, в которых есть Jenkinsfile. Когда создаётся ветка, Jenkins обнаруживает её через webhook или периодическое сканирование и начинает сборку; когда ветку удаляют, под-job тоже удаляется. С условиями when { branch 'main' } или changeRequest() один Jenkinsfile может вести себя по-разному для feature-веток, pull request-ов и main. Organization Folder поднимается на уровень выше и сканирует целую организацию GitHub или группу GitLab, создавая Multibranch-job-ы для каждого репозитория с Jenkinsfile.

По умолчанию — редко, но честные случаи есть. Изолированные или строго регулируемые среды, где SaaS control plane не разрешён, а организация уже хорошо эксплуатирует Jenkins. Сложные процессы с железом, например embedded- или device-тестирование, которые зависят от конкретных плагинов или настроек агентов. Очень большие сборочные фермы, где опытная команда эксплуатирует Jenkins с Kubernetes-агентами, JCasC и Shared Libraries дешевле, чем hosted-минуты. Против: эксплуатационная нагрузка, риски безопасности плагинов, специфичные навыки Groovy и более слабый developer experience, чем у встроенного CI. Если код в GitLab или GitHub Enterprise Server, их CI с self-hosted раннерами обычно даёт тот же on-premises контроль при меньшей поддержке, так что Jenkins я бы выбрал только с ясной причиной и командой, которая будет им владеть.

Один гигантский контроллер становится единой точкой отказа и узким местом по производительности, потому что логика Groovy-пайплайнов, UI и плагины работают там. Распространённый паттерн — несколько контроллеров, разделённых по бизнес-подразделениям или уровню доверия, каждый управляется одинаково через Configuration as Code и выверенный образ с плагинами, возможно с CloudBees CI или похожими инструментами для централизованного управления. Агенты — эфемерные поды или VM с автомасштабированием. Shared Libraries дают стандартные шаги пайплайна, версионированные и протестированные. Команды получают папки с ограниченными credentials и правами. Мониторинг покрывает время в очереди, загрузку executor-ов, heap контроллера и диск. Компромисс — накладные расходы на управление парком против радиуса поражения: больше контроллеров — больше обновлений, которые надо оркестрировать, зато плохой плагин или вышедший из-под контроля job затрагивает только часть организации.

Нужно сочетание нескольких мер. В конфигурации Multibranch настройте доверие так, чтобы pull request-ы из форков или от участников без прав на запись собирались с Jenkinsfile из целевой ветки, а не со своим изменённым. Ограничьте credentials папками и вообще не давайте сборкам pull request-ов production credentials; deploy credentials привязываются только в стадиях, которые выполняются в main. Маскирование помогает, но легко обходится кодированием, так что мерой контроля оно не является. Держите Groovy-песочницу включённой и не одобряйте рискованные сигнатуры скриптов. Требуйте код-ревью для изменений Jenkinsfile и Shared Library через branch protection. Для самых ценных секретов используйте короткоживущие credentials из Vault, чтобы даже утечка быстро истекала. Базовый принцип: любой, кто может менять код пайплайна, может использовать любой секрет, до которого этот пайплайн дотягивается.