CI/CD для вайбкодинга: деплой без простоя и откат за 1 минуту

Ты можешь генерировать код ИИ хоть каждый час, но без CI/CD любой релиз в прод становится лотереей. Пока выкладка делается «руками», у тебя всегда есть риск: забыли миграцию, не проверили health, затёрли .env, получили даунтайм.

Ниже рабочая схема, которая подходит для вашего формата сайта: быстро, без переусложнения и с реальным контролем качества.

Короткий ответ

CI/CD нужен даже соло-разработчику, если проект уже в проде и на нём есть пользователи. Минимум для взрослого релиза:

1. Автосборка и автотесты на каждый push.
2. Деплой в неактивную среду (blue/green или аналог).
3. Обязательный health-check перед переключением трафика.
4. Явный rollback-скрипт (одна команда).

Если этих четырёх пунктов нет, «релиз без простоя» фактически не гарантирован.

Где CI/CD даёт максимум пользы

• Когда обновления выходят чаще 1 раза в неделю.
• Когда есть авторизация, платежи, вебхуки, интеграции.
• Когда проект поддерживается через ИИ-ассистентов и легко допустить регрессию.
• Когда нужен предсказуемый откат без ночных аварий.

Минимальная архитектура релиза

Для большинства проектов на Node/Python/Go достаточно:

• GitHub Actions как orchestration layer.
• Docker-образ как единый артефакт.
• Две runtime-среды (blue и green).
• Reverse proxy (Nginx/Traefik) для переключения трафика.
• Проверка /health перед switch.

Готовый промпт для ИИ (копируй)

Ты senior DevOps.

Нужен production-ready CI/CD пайплайн для веб-приложения.

Контекст:

- стек: [укажи стек]

- деплой: Docker на VPS

- стратегия: blue-green

- цель: zero-downtime + rollback за 1 команду

Сделай:

1) .github/workflows/deploy.yml

2) Dockerfile (multi-stage, non-root)

3) docker-compose.prod.yml с blue/green сервисами

4) switch.sh и rollback.sh

5) health-check сценарий до переключения

6) короткую инструкцию запуска

Требования:

- не хранить секреты в репозитории

- fail-fast на тестах

- отключение деплоя при падении health-check

- логирование шагов без утечки токенов

Пример workflow (база, которую можно адаптировать)

name: Deploy Production

on:

push:

branches: ["main"]

jobs:

deploy:

runs-on: ubuntu-latest

steps:

- name: Checkout

uses: actions/checkout@v4

- name: Set up Docker Buildx

uses: docker/setup-buildx-action@v3

- name: Build image

run: docker build -t registry.example.com/app:${{ github.sha }} .

- name: Push image

run: docker push registry.example.com/app:${{ github.sha }}

- name: Deploy to inactive slot

run: ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} "cd /opt/app && ./deploy-to-inactive.sh ${{ github.sha }}"

- name: Health check

run: ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} "cd /opt/app && ./health-check.sh"

- name: Switch traffic

run: ssh ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} "cd /opt/app && ./switch.sh"

Антипаттерны, которые убивают релизы

• Деплой напрямую на единственный инстанс без промежуточной проверки.
• Отсутствие rollback-команды (откат «руками» = долго и рискованно).
• Проверка только «контейнер поднялся», без реального HTTP health-check.
• Секреты в .env внутри репозитория.
• Миграции БД, несовместимые с предыдущей версией приложения.

Чеклист перед продом

1. Есть отдельные секреты для staging и production.
2. Docker-образ собирается повторяемо (multi-stage, pinned base image).
3. /health проверяет не только процесс, но и доступ к БД/кэшу.
4. Rollback проверен на практике минимум один раз.
5. После релиза отслеживаются 4 DORA-метрики.

Что читать дальше

• Docker для новичка: полный гайд по запуску, образам и контейнерам
• Чистая архитектура: как не превратить проект в спагетти
• Подключение домена к Cloudflare: рабочая схема без ошибок
• Почему «оно работает» не равно качеству: проверка кода от ИИ