Переход с Jenkins на GitHub Actions — частый шаг для команд, которые хотят упростить CI/CD, сократить поддержку инфраструктуры и теснее связать пайплайны с репозиторием. Но миграция без плана легко приводит к падению сборок, потере секретов и хаосу в деплое.
Ниже — практический маршрут, как перенести Jenkins в GitHub Actions без боли.
-
1. Проведите аудит текущего Jenkins
Сначала зафиксируйте:
- какие job и pipeline реально используются
- какие плагины критичны
- где хранятся секреты
- какие агенты нужны: Linux, Windows, Docker
- какие этапы есть: build, test, lint, package, deploy
Важно отделить «исторический мусор» от нужных сценариев. Часто 20–30% job уже не актуальны. 🧹
-
2. Определите стратегию миграции
Есть 2 подхода:
- полный перенос сразу — быстрее, но рискованнее
- поэтапная миграция — безопаснее для production
На практике лучше переносить по сервисам или по типам задач: сначала CI, потом CD.
-
3. Сопоставьте Jenkins pipeline с GitHub Actions
В Jenkins логика обычно живёт в
Jenkinsfile, в GitHub Actions — в.github/workflows/*.yml.Что нужно сопоставить:
- stages → jobs / steps
- agents → runners
- environment variables → env
- credentials → secrets
- cron/job triggers →
on:и schedule
-
4. Подготовьте runners
GitHub Actions предлагает:
- GitHub-hosted runners — быстро и просто
- self-hosted runners — если нужны доступ в закрытую сеть, особые зависимости или контроль среды
Если в Jenkins использовались кастомные агенты, почти наверняка часть задач уйдёт на self-hosted runner. 🖥️
-
5. Перенесите секреты и доступы
Никогда не копируйте секреты в YAML. Используйте:
- GitHub Secrets
- Environment Secrets
- OIDC для доступа к AWS/Azure/GCP без статичных ключей
Это не просто перенос, а шанс улучшить безопасность. 🔐
-
6. Перепишите pipeline
Типовой workflow включает:
- checkout кода
- установку зависимостей
- сборку
- тесты
- публикацию артефактов
- деплой
Полезно сразу выделить повторяющиеся части в:
- reusable workflows
- composite actions
Это заменяет часть общей логики, которая раньше часто пряталась в shared libraries Jenkins.
-
7. Проверьте интеграции
Отдельно протестируйте:
- Docker build/push
- уведомления в Slack/Telegram
- публикацию артефактов
- работу с Nexus, Artifactory, S3
- деплой в Kubernetes, VM или serverless
Основная ошибка миграции — перенести сборку, но забыть хвосты интеграций. 📦
-
8. Запустите параллельный режим
На время миграции держите Jenkins и GitHub Actions параллельно:
- сравнивайте время сборки
- сверяйте артефакты
- проверяйте одинаковость тестов
- валидируйте деплой на staging
Это снижает риск поломки production. ✅
-
9. Переключите production и удалите legacy
Когда новые workflow стабильно работают:
- переносите основные триггеры
- обновляйте документацию
- отключайте старые job
- удаляйте неиспользуемые плагины и ноды Jenkins
Не оставляйте «временно» старый Jenkins без владельца — это быстро превращается в технический долг. 🧱
Что в итоге даёт GitHub Actions
- меньше поддержки CI-инфраструктуры
- workflow рядом с кодом
- проще code review для пайплайнов
- удобная интеграция с GitHub ecosystem
- масштабирование без зоопарка плагинов
Коротко: успешная миграция с Jenkins на GitHub Actions — это не переписывание YAML, а ревизия процессов CI/CD, секретов, агентов и интеграций. Чем лучше аудит в начале, тем спокойнее переход в конце.
👀 Заодно посмотрите подборку каналов про IT — там регулярно выходят практические материалы по DevOps, CI/CD, облакам и автоматизации.