CI/CD для сайта: как мы деплоим без простоя

Пайплайн — это последовательность шагов, которые выполняются автоматически после каждого изменения. У типичного веб-проекта он выглядит так:

GitHub Actions — самый популярный инструмент CI/CD для небольших проектов. Он бесплатен для публичных репозиториев и даёт 2 000 минут в месяц для приватных. Конфигурация — один YAML-файл в папке .github/workflows/.

Пример для Rust-приложения на VPS:

name: Deploy

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: dtolnay/rust-toolchain@stable
      - name: Run tests
        run: cargo test --all
      - name: Lint
        run: cargo clippy -- -D warnings

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: dtolnay/rust-toolchain@stable
      - name: Build release
        run: cargo build --release
      - name: Copy binary to server
        uses: appleboy/scp-action@v0.1.7
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_KEY }}
          source: "target/release/rusupovkusu"
          target: "/opt/app/"
      - name: Restart service
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_KEY }}
          script: sudo systemctl restart rusupovkusu

Секреты (адрес сервера, ключи) хранятся в настройках репозитория и не видны в коде. Каждый push в main автоматически запускает тесты, сборку и деплой.

Для Python или Node.js пайплайн аналогичный — меняется только шаг сборки. Для сайтов на PHP можно использовать Deployer или Envoyer — специализированные инструменты с более удобным синтаксисом для веб-проектов.

Простой вопрос: если сервис перезапускается, что происходит с пользователями, которые в этот момент на сайте? Если перезапуск занимает 3 секунды, они увидят ошибку. Если 30 секунд — точно уйдут. Zero-downtime решает эту проблему.

Blue-green deploy. На сервере работают две версии приложения: синяя (текущая) и зелёная (новая). Пока зелёная поднимается, трафик идёт на синюю. Как только зелёная готова — трафик переключается на неё. Откат — мгновенное переключение обратно.

Rolling update. Если приложение работает в нескольких экземплярах (например, в Kubernetes), обновляется по одному. Остальные продолжают обслуживать запросы.

Пример systemd-юнита для zero-downtime:

[Unit]
Description=Rusu po Vkusu site
After=network.target

[Service]
Type=simple
User=deploy
WorkingDirectory=/opt/app
ExecStart=/opt/app/rusupovkusu
Restart=always
RestartSec=2

[Install]
WantedBy=multi-user.target

Restart=always означает, что если сервис упадёт, systemd поднимет его за 2 секунды. А при деплое новый бинарник заменяет старый, и systemctl restart перезапускает сервис практически мгновенно — Rust-бинарник стартует за миллисекунды.

Код можно откатить мгновенно — старый бинарник всегда под рукой. А вот база данных — сложнее. Если миграция удалила колонку с данными, откат кода не вернёт данные. Именно поэтому миграции — самая ответственная часть деплоя.

Правила безопасных миграций:

• Сначала добавляй, потом удаляй. Нельзя удалять колонку в той же миграции, где добавляется новая. Сначала добавляем новую колонку, пишем код, который использует обе, потом удаляем старую в отдельной миграции.
• Никаких переименований. Переименование колонки — это «удалить + добавить», с потерей данных. Вместо этого — создать новую и скопировать данные.
• Обязательные бэкапы. Перед применением миграций на продакшене — снапшот базы. Если что-то пойдёт не так, восстановление занимает минуты.
• Тестовый прогон. Все миграции сначала прогоняются на копии продакшена. Если времени на копию нет — на крайний случай на dev-базе, но с реальными данными.

Всё вышеописанное — работа инженера, а не клиента. Но результат чувствуется именно клиентом.

• Правки вносятся за минуты, а не дни. Попросили поправить текст на сайте — разработчик сделал push — через 2 минуты всё на проде.
• Обновления не ломают сайт. Автотесты ловят ошибки до продакшена. Если что-то проскочило — откат за 30 секунд.
• Никаких «обновляемся, зайдите через 10 минут». Zero-downtime означает, что клиенты вообще не замечают обновлений.
• История изменений. Любое изменение можно найти: кто, когда, зачем. Если что-то сломалось — понятно, что именно и как исправить.
• Скорость реакции. Если найден серьёзный баг — исправление и деплой занимают минуты, а не часы. Для бизнеса это критично.