Привет, я Максим, веб-разработчик. CI/CD — это когда вы пушите код в Git, и через две минуты изменения уже на боевом сайте. Без ручного копирования файлов по FTP, без подключения по SSH к серверу, без вопросов «а ты точно залил последнюю версию?». Я настраиваю CI/CD на каждом проекте — и за годы работы убедился, что это одна из тех инвестиций, которая окупается с первого дня. Расскажу подробно: что это, зачем, как настроить, и какие ошибки допускают чаще всего.

Что такое CI/CD простыми словами

За аббревиатурой скрываются два процесса, которые работают в связке.

CI — Continuous Integration (непрерывная интеграция). При каждом коммите в репозиторий автоматически запускается набор проверок: сборка проекта, линтеры (проверка стиля кода), тесты, проверка типов TypeScript. Если что-то сломалось — вы узнаёте мгновенно, а не через три дня, когда клиент позвонит и скажет, что сайт не работает. CI ловит ошибки до того, как они попадают в продакшен.

CD — Continuous Deployment (непрерывный деплой). После успешного прохождения всех проверок код автоматически доставляется на боевой сервер. Без ручных действий, без промежуточных шагов, без человеческого фактора. Вы нажали «Merge» в pull request — и через две-три минуты изменения живут на сайте.

Зачем это нужно бизнесу, а не только разработчикам

Многие думают, что CI/CD — это инструмент для больших команд и enterprise-проектов. На самом деле, даже для сайта, который ведёт один разработчик, автоматический деплой критически важен.

Без CI/CD типичный процесс выглядит так: собрал проект локально на своём компьютере, подключился к серверу по SSH или FTP, загрузил файлы вручную, перезапустил серверные процессы, открыл сайт в браузере и проверил, что ничего не сломалось. Это занимает пятнадцать-тридцать минут, и на каждом шаге есть риск ошибки: забыл скомпилировать CSS, загрузил не тот файл, перезаписал конфиг базы данных. Я видел, как разработчики случайно удаляли базу данных на продакшене при ручном деплое — восстанавливали из бэкапа всю ночь.

С CI/CD: сделали push в main-ветку — через две минуты изменения на боевом сайте. Автоматически. Каждый раз одинаково. Без ошибок. И если что-то пошло не так — откат к предыдущей версии одной командой.

На моих проектах переход на CI/CD экономит в среднем два-четыре часа в неделю на рутинных деплоях. За год — это больше ста часов, которые разработчик тратит на полезную работу вместо ручного копирования файлов.

GitHub Actions — мой основной инструмент

Для большинства проектов я использую GitHub Actions — встроенную систему CI/CD в GitHub. Она бесплатна для публичных репозиториев и включает 2 000 минут бесплатных вычислений в месяц для приватных. Для среднего проекта этого хватает с запасом.

Настройка делается через YAML-файл, который лежит прямо в репозитории в папке .github/workflows. Это удобно: конфигурация CI/CD — часть кода проекта, она версионируется в Git, и любой разработчик может увидеть и изменить пайплайн.

Мой типичный пайплайн для Next.js-сайта состоит из нескольких шагов. Триггер — push в main-ветку (или merge pull request). Первый шаг — checkout кода из репозитория. Второй — установка Node.js нужной версии и зависимостей через npm ci (более строгий и быстрый вариант npm install). Третий — сборка проекта через npm run build. Если на этом шаге происходит ошибка (например, TypeScript нашёл ошибку типов или сборка упала из-за отсутствующего модуля) — деплой не происходит, и я получаю уведомление в Telegram. Четвёртый шаг — деплой на сервер через SSH (rsync или Docker-контейнер).

Между сборкой и деплоем я часто добавляю дополнительные проверки: запуск линтера ESLint (чтобы код соответствовал стандартам), проверку типов TypeScript (tsc --noEmit), запуск автотестов (Jest для юнит-тестов, Playwright для e2e). Если хоть одна проверка падает — деплой блокируется.

Варианты деплоя на разные платформы

Деплой на VPS (Yandex Cloud, Selectel, Timeweb Cloud). Два основных подхода. Первый — rsync через SSH: после сборки утилита rsync копирует изменённые файлы на сервер по защищённому каналу. Простой, надёжный, подходит для статических сайтов и несложных Node.js-приложений. Второй — Docker: собираю Docker-образ с приложением, пушу в container registry (Docker Hub, GitHub Container Registry, Yandex Container Registry), на сервере выполняю docker pull и docker-compose up. Для сложных приложений с зависимостями (база данных, Redis, очереди) Docker-подход надёжнее и воспроизводимее.

Деплой на Vercel или Netlify. Если сайт хостится на этих платформах — CI/CD настроен из коробки, ноль конфигурации. Подключаете GitHub-репозиторий, выбираете ветку — и каждый push автоматически деплоится. Для Next.js-проектов Vercel — идеальный вариант: оптимизированный деплой с поддержкой ISR, preview deployments для каждого pull request (можно показать клиенту изменения до merge в main), edge-функции. Именно поэтому для многих моих клиентов я выбираю Vercel — это не просто хостинг, а полноценная платформа с CI/CD внутри.

GitLab CI/CD. Если команда использует GitLab вместо GitHub — аналогичная система, настраиваемая через файл .gitlab-ci.yml. Бесплатные shared runners для публичных проектов. По функциональности не уступает GitHub Actions, а для self-hosted GitLab — даже превосходит, потому что runner можно запускать на собственных серверах.

Что ещё добавить в пайплайн для максимальной надёжности

Базовый пайплайн (сборка + деплой) — это минимум. Для серьёзных проектов я добавляю дополнительные шаги.

Линтинг через ESLint и Stylelint — автоматическая проверка качества кода и стилей. Ловит типичные ошибки до того, как они попадут на продакшен. Автотесты — Jest для юнит-тестов бизнес-логики, Playwright или Cypress для end-to-end тестирования (автоматизированный «пользователь» проходит по ключевым сценариям: регистрация, оформление заказа, отправка формы). Проверка типов TypeScript — строгая типизация ловит целый класс ошибок на этапе компиляции.

Lighthouse CI — автоматический аудит производительности при каждом деплое. Если Performance упал ниже заданного порога (например, 75) — деплой блокируется. Это спасает от ситуации, когда разработчик случайно добавил тяжёлое изображение или неоптимизированный скрипт, и сайт замедлился.

Уведомления — в Telegram или Slack. Успешный деплой, провалившийся деплой, результаты тестов — всё приходит в чат, и команда всегда в курсе состояния проекта.

Типичные ошибки при внедрении CI/CD

Деплоить из локальной машины «по старинке» параллельно с CI/CD. Если кто-то в команде продолжает заливать файлы по FTP — CI/CD теряет смысл, потому что состояние сервера начинает расходиться с тем, что в Git.

Деплоить напрямую в main без pull request и code review. CI/CD — не повод отменять ревью кода. Наоборот: автоматические проверки дополняют ручное ревью, а не заменяют его.

Хранить секреты (API-ключи, пароли базы данных, токены сервисов) в коде. Их нужно хранить в переменных окружения CI-системы (GitHub Secrets, GitLab Variables). Утечка секретов через публичный репозиторий — реальная угроза.

Не настраивать rollback — способ быстро откатить деплой, если что-то пошло не так на продакшене. Это может быть git revert с автоматическим ре-деплоем или хранение нескольких последних версий на сервере с возможностью переключения через symlink.

CI/CD — одна из тех вещей, на настройку которых вы тратите два-три часа один раз, а экономите сотни часов за год. Если вы до сих пор деплоите сайт по FTP, копируя файлы вручную — сделайте себе подарок и настройте автоматический деплой. В 2026 году ручной деплой — это как печатать документы на пишущей машинке.