Автоматизация деплоя: сэкономьте 6 ч на 30‑сек задаче

Пошаговый гайд по автоматизации деплоя с monitoring и automation: экономьте 6 ч, избегайте лишних зависимостей и упрощайте процесс за 30 сек.

Средний
Алексей Кузнецов
Алексей Кузнецов
Системный администратор9 июня 2026 г.4 мин чтения

Требования

  • Базовые знания Bash или Python
  • Доступ к серверу по SSH
  • Установленный Git
  • Понимание CI/CD-пайплайнов

Оцените реальную стоимость автоматизации

Прежде чем писать скрипт, посчитайте: сколько раз в неделю вы выполняете задачу, сколько времени она занимает и сколько часов уйдёт на автоматизация. Если задача выполняется реже раза в неделю и занимает меньше минуты — автоматизация, скорее всего, не окупится. Запишите метрики: частота выполнения, текущее время, ожидаемое время на автоматизацию.

# Простая таблица для оценки
# | Метрика | Значение |
# |---|---|
# | Частота выполнения | 2 раза/неделю |
# | Время вручную | 30 сек |
# | Время на автоматизацию | 6 часов |
# | Окупаемость | ~26 недель |

Начните с простого скрипта деплоя

Создайте минимальный bash-скрипт, который делает ровно то, что вы делаете вручную. Не добавляйте обработку ошибок, роллбэки и мониторинг на этом этапе — только основной путь. Скрипт должен быть читаемым и понятным через 6 месяцев.

#!/usr/bin/env bash
set -euo pipefail

# deploy.sh — минимальный скрипт деплоя

echo "→ Сборка проекта..."
npm run build

echo "→ Копирование на сервер..."
rsync -avz --delete ./dist/ user@server:/var/www/app/

echo "→ Перезапуск сервиса..."
ssh user@server 'sudo systemctl restart myapp'

echo "✅ Деплой завершён: $(date '+%Y-%m-%d %H:%M:%S')"

Добавьте базовую проверку здоровья

После деплоя убедитесь, что приложение действительно работает. Один HTTP-запрос к health-endpoint — этого достаточно для начала. Не подключайте три системы мониторинга сразу — начните с одного проверочного запроса.

#!/usr/bin/env bash
set -euo pipefail

HEALTH_URL="https://example.com/health"
MAX_RETRIES=5
RETRY_DELAY=10

# ... (шаги деплоя из предыдущего скрипта) ...

echo "→ Проверка здоровья..."
for i in $(seq 1 $MAX_RETRIES); do
  STATUS=$(curl -s -o /dev/null -w '%{http_code}' "$HEALTH_URL")
  if [ "$STATUS" = "200" ]; then
    echo "✅ Приложение здорово (попытка $i)"
    exit 0
  fi
  echo "⚠️  Попытка $i: статус $STATUS, повтор через ${RETRY_DELAY}с..."
  sleep $RETRY_DELAY
done

echo "❌ Приложение не ответило после $MAX_RETRIES попыток"
exit 1

Реализуйте простой роллбэк

Сохраняйте предыдущую версию и добавьте скрит отката. Это проще, чем кажется: достаточно хранить символическую ссылку на предыдущий релиз и уметь переключаться обратно.

#!/usr/bin/env bash
set -euo pipefail

DEPLOY_DIR="/var/www/app"
RELEASES_DIR="/var/www/releases"
CURRENT_LINK="$DEPLOY_DIR/current"

rollback() {
  echo "→ Откат к предыдущей версии..."
  PREVIOUS=$(readlink -f "$CURRENT_LINK" | xargs dirname | xargs ls -td | sed -n '2p')
  if [ -z "$PREVIOUS" ]; then
    echo "❌ Нет предыдущей версии для отката"
    exit 1
  fi
  ln -sfn "$PREVIOUS" "$CURRENT_LINK"
  sudo systemctl restart myapp
  echo "✅ Откат к $(basename $PREVIOUS) завершён"
}

# Использование в основном скрипте:
# trap rollback ERR  # автоматический откат при ошибке

Подключите один инструмент мониторинга

Выберите один инструмент для отслеживания деплоев. Для начала достаточно простого логирования в файл или отправки уведомления в Slack/Telegram. Не устанавливайте Prometheus, Grafana и Datadog одновременно — это и есть та самая «зависимость от трёх систем мониторинга».

#!/usr/bin/env bash

# Вариант 1: логирование в файл
LOG_FILE="/var/log/deployments.log"
log_deploy() {
  echo "$(date -Iseconds) | $1 | status=$2 | duration=${3}s" >> "$LOG_FILE"
}

# Вариант 2: уведомление в Telegram
TELEGRAM_BOT_TOKEN="your-token"
TELEGRAM_CHAT_ID="your-chat-id"

notify_telegram() {
  local message="🚀 *Деплой*\n$1\nСтатус: $2"
  curl -s -X POST \
    "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage" \
    -d chat_id="$TELEGRAM_CHAT_ID" \
    -d text="$message" \
    -d parse_mode="Markdown" > /dev/null
}

# Использование:
# log_deploy "myapp" "success" "45"
# notify_telegram "myapp v1.2.3" "✅ Успешно"

Интегрируйте в CI/CD пайплайн

Подключите скрипт к вашей CI/CD-системе. Для GitHub Actions — создайте workflow-файл, который запускает деплой при пуше в main-ветку. Это стандартный подход, который не требует кастомных решений.

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup SSH
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          ssh-keyscan -H ${{ secrets.SERVER_IP }} >> ~/.ssh/known_hosts

      - name: Deploy
        run: |
          chmod +x deploy.sh
          ./deploy.sh
        env:
          SERVER_IP: ${{ secrets.SERVER_IP }}

Документируйте и остановитесь

Напишите README к вашему скрипту деплоя: что он делает, как запустить, как откатить. После этого — остановитесь. Не добавляйте фичи «на будущее». Если через месяц понадобится что-то новое — добавите тогда. Помните: лучшая автоматизация — та, которую не нужно поддерживать.

# Deployment

## Быстрый старт

```bash
# Деплой последней версии
./deploy.sh

# Ручной откат
./deploy.sh --rollback
```

## Требования
- SSH-доступ к серверу
- rsync
- Node.js 18+

## Мониторинг
- Логи: `/var/log/deployments.log`
- Уведомления: Telegram-канал #deployments

## Откат
```bash
./deploy.sh --rollback
```

Автоматизация деплоя: не тратьте 6 часов на 30-секундную задачу

Описание: Пошаговый гайд по разумной автоматизации деплоя с мониторингом — без избыточной сложности и зависимостей. Научитесь окупать время на автоматизацию и не усложнять процесс.

Предварительные требования

  • Базовые знания Bash или Python
  • Доступ к серверу по SSH
  • Установленный Git
  • Понимание CI/CD-пайплайнов

Шаг 1: Оцените реальную стоимость автоматизации

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

Таблица для оценки окупаемости

Запишите метрики: частота выполнения, текущее время, ожидаемое время на автоматизацию.

# Простая таблица для оценки
# | Метрика | Значение |
# |---|---|
# | Частота выполнения | 2 раза/неделю |
# | Время вручную | 30 сек |
# | Время на автоматизацию | 6 часов |
# | Окупаемость | ~26 недель |

Шаг 2: Начните с простого скрипта деплоя

Создайте минимальный bash-скрипт, который делает ровно то, что вы делаете вручную. Не добавляйте обработку ошибок, роллбэки и мониторинг на этом этапе — только основной путь. Скрипт должен быть читаемым и понятным через 6 месяцев.

Минимальный скрипт

#!/usr/bin/env bash
set -euo pipefail

# deploy.sh — минимальный скрипт деплоя

echo "→ Сборка проекта..."
npm run build

echo "→ Копирование на сервер..."
rsync -avz --delete ./dist/ user@server:/var/www/app/

echo "→ Перезапуск сервиса..."
ssh user@server 'sudo systemctl restart myapp'

echo "✅ Деплой завершён: $(date '+%Y-%m-%d %H:%M:%S')"

Шаг 3: Добавьте базовую проверку здоровья

После деплоя убедитесь, что приложение действительно работает. Один HTTP-запрос к health-endpoint — этого достаточно для начала. Не подключайте три системы мониторинга сразу — начните с одного проверочного запроса.

Health-check с повторами

#!/usr/bin/env bash
set -euo pipefail

HEALTH_URL="https://example.com/health"
MAX_RETRIES=5
RETRY_DELAY=10

# ... (шаги деплоя из предыдущего скрипта) ...

echo "→ Проверка здоровья..."
for i in $(seq 1 $MAX_RETRIES); do
  STATUS=$(curl -s -o /dev/null -w '%{http_code}' "$HEALTH_URL")
  if [ "$STATUS" = "200" ]; then
    echo "✅ Приложение здорово (попытка $i)"
    exit 0
  fi
  echo "⚠️  Попытка $i: статус $STATUS, повтор через ${RETRY_DELAY}с..."
  sleep $RETRY_DELAY
done

echo "❌ Приложение не ответило после $MAX_RETRIES попыток"
exit 1

Шаг 4: Реализуйте простой роллбэк

Сохраняйте предыдущую версию и добавьте скрипт отката. Это проще, чем кажется: достаточно хранить символическую ссылку на предыдущий релиз и уметь переключаться обратно.

Функция отката

#!/usr/bin/env bash
set -euo pipefail

DEPLOY_DIR="/var/www/app"
RELEASES_DIR="/var/www/releases"
CURRENT_LINK="$DEPLOY_DIR/current"

rollback() {
  echo "→ Откат к предыдущей версии..."
  PREVIOUS=$(readlink -f "$CURRENT_LINK" | xargs dirname | xargs ls -td | sed -n '2p')
  if [ -z "$PREVIOUS" ]; then
    echo "❌ Нет предыдущей версии для отката"
    exit 1
  fi
  ln -sfn "$PREVIOUS" "$CURRENT_LINK"
  sudo systemctl restart myapp
  echo "✅ Откат к $(basename $PREVIOUS) завершён"
}

# Использование в основном скрипте:
# trap rollback ERR  # автоматический откат при ошибке

Шаг 5: Подключите один инструмент мониторинга

Выберите один инструмент для отслеживания деплоев. Для начала достаточно простого логирования в файл или отправки уведомления в Slack/Telegram. Не устанавливайте Prometheus, Grafana и Datadog одновременно — это и есть та самая «зависимость от трёх систем мониторинга».

Логирование и уведомления

#!/usr/bin/env bash

# Вариант 1: логирование в файл
LOG_FILE="/var/log/deployments.log"
log_deploy() {
  echo "$(date -Iseconds) | $1 | status=$2 | duration=${3}s" >> "$LOG_FILE"
}

# Вариант 2: уведомление в Telegram
TELEGRAM_BOT_TOKEN="your-token"
TELEGRAM_CHAT_ID="your-chat-id"

notify_telegram() {
  local message="🚀 *Деплой*\n$1\nСтатус: $2"
  curl -s -X POST \
    "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage" \
    -d chat_id="$TELEGRAM_CHAT_ID" \
    -d text="$message" \
    -d parse_mode="Markdown" > /dev/null
}

# Использование:
# log_deploy "myapp" "success" "45"
# notify_telegram "myapp v1.2.3" "✅ Успешно"

Шаг 6: Интегрируйте в CI/CD-пайплайн

Подключите скрипт к вашей CI/CD-системе. Для GitHub Actions — создайте workflow-файл, который запускает деплой при пуше в main-ветку. Это стандартный подход, который не требует кастомных решений. Если вы используете GitLab, аналогичный процесс описан в нашей статье про настройку GitLab Runner.

Workflow для GitHub Actions

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup SSH
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          ssh-keyscan -H ${{ secrets.SERVER_IP }} >> ~/.ssh/known_hosts

      - name: Deploy
        run: |
          chmod +x deploy.sh
          ./deploy.sh
        env:
          SERVER_IP: ${{ secrets.SERVER_IP }}

Шаг 7: Документируйте и остановитесь

Напишите README к вашему скрипту деплоя: что он делает, как запустить, как откатить. После этого — остановитесь. Не добавляйте фичи «на будущее». Если через месяц понадобится что-то новое — добавите тогда.

Шаблон документации

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

# Deployment

## Быстрый старт

# Деплой последней версии
./deploy.sh

# Ручной откат
./deploy.sh --rollback

## Требования
- SSH-доступ к серверу
- rsync
- Node.js 18+

## Мониторинг
- Логи: `/var/log/deployments.log`
- Уведомления: Telegram-канал #deployments

## Откат
./deploy.sh --rollback

Заключение

Автоматизация деплоя не обязана быть сложной. Семь шагов — от оценки окупаемости до документации — дают рабочую систему без избыточных зависимостей. Начните с простого скрипта, добавьте проверку здоровья и роллбэк, подключите одно уведомление — и остановитесь. Остальное приложится по мере необходимости.

Поделиться:TelegramX / TwitterVK