Настройка отказоустойчивого CI/CD пайплайна на GitHub Actions
Суть без длинного чтения
Если нужен быстрый вывод по теме, ниже собрали главное: что это значит, когда проблема уже влияет на бизнес и какой следующий шаг обычно даёт пользу быстрее всего.
О чем статья
Разбор пайплайна на GitHub Actions с Telegram-уведомлениями и Zero-Downtime деплоем.
В какой момент это становится проблемой
Проблема созрела, если релизы делаются вручную, production плохо наблюдаем, а сбои превращаются в дорогой и плохо управляемый процесс.
Что делать после прочтения
Покажем, где у вас ломается release process: pipeline, rollback, production-контур, диагностика или эксплуатационная дисциплина после выкладки.
#01Зачем нужен CI/CD?
Ручной деплой — это всегда человеческий фактор. CI/CD (Continuous Integration / Continuous Deployment) позволяет автоматизировать проверку кода, тестирование и доставку на сервер.
#02Архитектура нашего пайплайна
В SmartCG мы используем GitHub Actions. Наш стандартный пайплайн делится на 2 файла: ci.yml и cd.yml.
#03CI: Проверки
- Security Audit: Запускаем npm audit для поиска уязвимостей.
- Build Check: Проверяем, компилируется ли TypeScript код.
- Linter: Прогон ESLint.
#04CD: Деплой
Если CI прошел успешно, запускается деплой:
- Подключение к серверу по SSH (через appleboy/ssh-action).
- Генерация .env файлов из GitHub Secrets.
- Сборка Docker-образов (docker compose build).
- Перезапуск контейнеров (docker compose up -d).
#05Уведомления в Telegram
Мы добавили шаг, который при падении пайплайна выгружает последние 100 строк логов и отправляет их документом в Telegram. Это позволяет разработчику узнать причину ошибки, даже не открывая GitHub.
Редакционная проверка и источники
Материал подготовлен как практический разбор и привязан к рабочим сценариям бизнеса, а не к абстрактной теории.
Что ещё посмотреть по этой задаче
Ниже материалы, которые помогают перейти от общего понимания проблемы к более предметному следующему шагу.
Как понять, что релизный процесс опасен для production: 8 красных флагов
Если каждая выкладка вызывает напряжение, созвоны и страх “лишь бы ничего не упало”, проблема чаще всего не в конкретном релизе, а в самом процессе.
Администрирование серверов и DevOps по SLA: чек-лист зрелой эксплуатации
Что должно быть в инфраструктуре, если бизнес не может позволить себе сбои при каждом обновлении.
Что должно входить в SLA для бизнес-критичной системы
Хороший SLA - это не только таблица с часами реакции. Для бизнеса важнее, чтобы у продукта появился управляемый контур поддержки, релизов и ответственности.
Куда идти после прочтения
Здесь не теория ради теории. Ниже собрали, какая услуга чаще всего решает похожую задачу на практике и какой кейс стоит открыть, если хотите быстро понять формат результата.
Технический аудит и план стабилизации web-проекта
Аудит текущего web-проекта с картой рисков, приоритетами и планом первой очереди.
Становится понятно, что именно нужно проверить в первую очередь: продукт, интеграции, инфраструктуру или работу подрядчиков.
Вы получаете список проблем по критичности: что уже бьёт по выручке и стабильности, а что можно оставить на второй этап.
Релизы до сих пор зависят от ручных действий и нервных выкладок?
Покажем, где у вас ломается release process: pipeline, rollback, production-контур, диагностика или эксплуатационная дисциплина после выкладки.
Технический аудит и план стабилизации web-проекта
Аудит текущего web-проекта с картой рисков, приоритетами и планом первой очереди.