CI/CD в 2026: когда нужны Jenkins, GitHub Actions, GitLab CI, Argo CD и Tekton
Когда речь идёт про CI/CD, Jenkins, GitHub Actions, GitLab CI, Argo CD и Tekton часто оказываются в одной таблице. Для первичного сравнения это удобно, но в 2026 такая таблица легко сбивает с толку. Одни инструменты решают задачу сборки и тестов рядом с репозиторием. Другие управляют деплоем в Kubernetes. Третьи являются конструктором внутренней платформы доставки.
Из-за этого вопрос «что выбрать» обычно сформулирован неправильно. Сначала нужно понять не бренд, а операционную модель: вам нужен встроенный CI у Git-провайдера, GitOps CD для кластера, Kubernetes-native pipeline engine или система, которая пережила десять лет enterprise-автоматизации и до сих пор живёт во многих компаниях. Потом уже выбирается продукт.
Jenkins умирает или нет
Если смотреть на Jenkins как на действующую enterprise-систему, ответ: нет, не умирает. Официальная документация Jenkins по-прежнему строится вокруг контроллера, агентов, лейблов и распределённого исполнения job-ов. Такая модель всё ещё работает там, где есть закрытые сети, hardware-лаборатории, code signing, нестандартные наборы инструментов и годы накопленных пайплайнов. (Jenkins)
Но как выбор с нуля Jenkins в 2026 почти всегда выглядит слабее встроенных CI-платформ. Не потому, что он «перестал запускать билд», а потому, что вместе с Jenkinsfile вы получаете отдельный продукт, который надо обновлять, бэкапить, защищать, чистить от лишних плагинов и удерживать в рабочем состоянии. Там, где GitHub Actions и GitLab CI уже встроены в повседневный процесс разработки, Jenkins для новой команды чаще ощущается не как ускоритель, а как дополнительный слой эксплуатации.
Отдельный маркер эпохи — судьба Jenkins X. В марте 2026 проект прямо написал, что имя Jenkins стало для него маркетинговым бременем: оно привлекало людей, которые ждали классический Jenkins, и отпугивало тех, кто искал альтернативу. Проект переименовался в JayeX, а оставшиеся интеграции с Jenkins объявлены deprecated. Это уже не «будущее Jenkins», а самостоятельная ветка эволюции. (JayeX)
Моя короткая версия такая: Jenkins не мёртв как установленная база, но как выбор по умолчанию для новых проектов уже мёртв. Его выбирают не потому, что он лучший в 2026, а потому, что цена миграции иногда выше цены боли.
GitHub Actions
GitHub Actions лучше всего подходит той части рынка, где код, pull request, code review и релизный процесс уже живут в GitHub. Сила Actions не в YAML как таковом, а в близости к репозиторию: workflow лежит рядом с кодом, статусы возвращаются прямо в PR, secrets и environments встроены в платформу, а экосистема готовых actions покрывает почти любые типовые задачи.
В 2026 GitHub продолжает вкладываться в эту модель. Компания пишет, что перевела все jobs на новую архитектуру, рассчитанную уже на десятки миллионов job-ов в день, и одновременно снизила цены на GitHub-hosted runners с 1 января 2026 года. Для стандартных hosted runners картина такая: Linux 1-core — $0.002/мин, Linux 2-core — $0.006/мин, Windows 2-core — $0.010/мин, macOS — $0.062/мин. Для публичных репозиториев стандартные hosted runners остаются бесплатными, а для приватных репозиториев действует включённая квота минут в зависимости от плана. (GitHub, GitHub, GitHub)
Самая показательная история 2026 года связана не с hosted, а с self-hosted runners. GitHub сначала объявил отдельный $0.002/мин cloud platform charge и для self-hosted, а потом отложил эту модель после негативной реакции пользователей. Это важный сигнал: self-hosted в экосистеме GitHub больше нельзя воспринимать как «вечно бесплатный способ запускать Actions на своём железе». Платформа явно движется к тому, чтобы монетизировать не только compute, но и control plane вокруг него. (GitHub)
GitHub Actions — лучший дефолт, если вы уже живёте в GitHub и не строите отдельную платформенную функцию. Его слабость тоже очевидна: вместе с удобством вы принимаете сильный lock-in к GitHub как к центру инженерного процесса.
GitLab CI
GitLab CI редко выигрывает как «самый модный CI», но очень часто выигрывает как самый цельный продукт. Если GitHub Actions силён своей близостью к workflow вокруг pull request, то GitLab CI силён тем, что живёт внутри более широкой SDLC-платформы: source, merge requests, registry, security scans, environments, runners и governance-механики лежат в одном слое.
У GitLab особенно прозрачна экономика hosted usage. На GitLab.com compute usage считается по формуле job duration / 60 * cost factor, а сам cost factor зависит от типа раннера и размера машины. Для Linux x86-64 small factor равен 1, для более крупных машин он растёт; у macOS и GPU-раннеров множитель существенно выше. Free tier на GitLab.com включает 400 compute minutes в месяц, а дополнительные 1000 минут стоят $10. Свои runners можно приносить отдельно, и их использование не съедает квоту shared runners. (GitLab, GitLab, GitLab)
Практический вывод простой. Если команда уже сидит в GitLab, уходить из него только ради «более модного CI» обычно бессмысленно. GitLab CI особенно хорош там, где важны единая governance-модель, групповые раннеры и предсказуемый административный контур. Но если компания не использует GitLab как основную платформу разработки, брать весь стек только ради CI/CD не всегда рационально.
Argo CD
Argo CD относится к другому слою, чем GitHub Actions и GitLab CI. Официально это declarative GitOps continuous delivery tool for Kubernetes. То есть Argo CD отвечает не на вопрос «где запускать тесты и сборки», а на вопрос «как кластер должен сходиться к состоянию, описанному в Git». (Argo CD)
Это видно даже в документации по automation from CI pipelines. Рекомендуемый поток выглядит так: CI собирает и публикует контейнерный образ, затем обновляет manifests в Git, и уже после этого Argo CD синхронизирует кластер с желаемым состоянием. Если у приложения включён automated sync, отдельный imperative deploy step в CI вообще становится необязательным. (Argo CD)
Поэтому Argo CD нужен не вместо CI, а рядом с CI. Он даёт аудитируемый GitOps-процесс, удобную работу с несколькими кластерами, разделение между репозиторием приложения и репозиторием конфигурации и более предсказуемый rollback через Git history. Но если вы деплоите один сервис на VPS через docker compose, добавлять Argo CD — это не современность, а лишняя сложность.
Tekton
Tekton — это уже другой класс системы. Официальная документация называет его cloud-native solution for building CI/CD pipelines, которая устанавливается как расширение Kubernetes и использует Custom Resources как базовые строительные блоки пайплайнов. То есть Tekton — не просто «ещё один CI», а Kubernetes-native слой, на котором можно строить собственную платформу доставки. (Tekton)
Поэтому Tekton особенно хорошо ложится на платформенную инженерию. В его терминологии есть Tasks, Pipelines, Triggers, Chains, каталоги переиспользуемых компонентов и сильная линия на безопасность цепочки поставки. В марте 2026 Tekton получил статус CNCF Incubating, что закрепило его как зрелый cloud-native building block, а не как нишевый эксперимент. (Tekton, CNCF)
Но всё это имеет цену. Tekton хорош, когда у вас уже есть Kubernetes как внутренняя платформа и команда, которая готова обслуживать не только приложения, но и сам слой доставки. Для небольшой продуктовой команды Tekton чаще всего не «свобода», а преждевременное строительство внутреннего PaaS.
Self-hosted runners
Self-hosted runners в 2026 нужны не потому, что «так дешевле по определению», а потому, что у них есть чёткие сценарии. Они оправданы, когда билдам нужен доступ в приватную сеть, внутренние артефакты, нестандартный набор инструментов, GPU, Arm, HSM/code signing, большие кэши или более жёсткий контроль над данными и задержками.
Но self-hosted runners почти всегда недооценивают. Как только вы уходите с управляемого исполнения, у вас появляется отдельная мини-платформа: autoscaling, очереди, обновления образов, патчи ОС, секреты, изоляция между job-ами, наблюдаемость, расследование падений и capacity planning. GitHub в своей 2026-коммуникации прямо пишет, что вкладывается в ARC, Scale Set Client, observability и другие enterprise-возможности вокруг self-hosted опыта. Это хорошее напоминание, что парк раннеров — полноценный продукт, а не бесплатное приложение к CI. (GitHub)
Именно поэтому правило простое: self-hosted runners берут по требованиям безопасности, сети или производительности. Их не стоит брать только потому, что команда романтизирует «своё железо» или хочет сэкономить на нескольких тысячах hosted minutes, не посчитав стоимость эксплуатации.
Какой CI/CD выбрать в 2026
Для большинства команд вопрос решается быстрее, если сначала определить свою операционную модель, а уже потом — инструмент.
| Сценарий | Что выбрать | Почему |
|---|---|---|
| Небольшая команда, весь код и review в GitHub | GitHub Actions | Самый короткий путь от commit до production без отдельной платформы |
| Команда уже живёт в GitLab и хочет единый SDLC-стек | GitLab CI | Source, CI, registry, governance и runners в одном продукте |
| Kubernetes-платформа с GitOps-процессом | GitHub Actions или GitLab CI + Argo CD | CI собирает артефакты, Argo CD делает declarative delivery |
| Внутренняя платформенная команда строит собственный слой доставки на Kubernetes | Tekton | Даёт примитивы и переиспользуемые блоки, а не только готовый UI для pipeline |
| Крупная legacy-организация с сотнями job-ов и особыми интеграциями | Jenkins | Боль миграции может быть выше пользы от переезда |
Если нужен один короткий совет без оговорок, он такой: в 2026 дефолтный выбор для новой команды — не Jenkins. Обычно это либо GitHub Actions, либо GitLab CI. Argo CD добавляется тогда, когда у вас уже есть Kubernetes и нужен GitOps CD. Tekton добавляется тогда, когда вы строите внутреннюю платформу. Jenkins остаётся там, где история компании уже слишком глубоко впаяна в его модель.
Короткий вывод
CI/CD в 2026 — это уже не рынок, где один инструмент должен «сделать всё». На практике команды выбирают между разными слоями delivery-стека: встроенный CI рядом с Git, GitOps-деплой для Kubernetes и платформенные примитивы для внутренней инженерной системы.
Поэтому вопрос «Jenkins или Argo CD» обычно означает, что команда ещё не развела CI и CD по слоям. Jenkins, GitHub Actions и GitLab CI отвечают за запуск автоматизации. Argo CD живёт рядом с ними как Kubernetes CD. Tekton чаще появляется не в команде из пяти человек, а в архитектуре внутренней платформы.
Если формулировать жёстко: Jenkins как символ выбора по умолчанию действительно умер. Jenkins как огромная установленная база будет жить ещё долго. GitHub Actions естественно подходит GitHub-центричным командам, GitLab CI силён как единая платформа, Argo CD стал стандартным ответом на GitOps-деплой в Kubernetes, а Tekton — инструментом для тех, кто хочет строить собственный движок доставки, а не просто запускать pipeline.
Самая дорогая ошибка здесь — не выбрать «не тот бренд», а взять инструмент из другого класса. Когда команде нужен обычный CI рядом с репозиторием, ей не нужен Tekton. Когда команде нужен GitOps CD для кластера, ей не нужен Jenkins вместо Argo CD. А когда команде нужен быстрый работающий процесс доставки, ей редко нужен отдельный зоопарк, который она будет поддерживать дольше, чем собственный продукт.