Что такое деплой и как сайт попадает в интернет?
Деплой (deployment) — это процесс размещения обновлённого кода сайта на рабочем сервере (продакшен). До деплоя сайт работает только на компьютере разработчика, после деплоя — доступен всем по адресу site.ru.
Этапы деплоя:
| Этап | Что делаем | Инструменты |
|---|---|---|
| 1. Подготовка | Тестируем локально, прогоняем тесты | pytest, ESLint |
| 2. Коммит | Сохраняем изменения в Git | git commit |
| 3. Push | Отправляем в удалённый репозиторий | GitHub, GitLab |
| 4. CI/CD | Автоматическая сборка и тесты | GitHub Actions, GitLab CI |
| 5. Деплой | Перенос на продакшен-сервер | Docker, Fabric, Ansible |
| 6. Миграции | Обновление структуры БД | Django migrations |
| 7. Проверка | Тестирование на продакшене | Ручное + автотесты |
Виды деплоя:
| Тип | Описание | Когда использовать |
|---|---|---|
| Ручной | Через FTP/SSH вручную | Маленькие проекты, редкие обновления |
| Полуавтоматический | Скрипт + ручной запуск | Средние проекты |
| Автоматический (CI/CD) | Полный автомат при push | Крупные проекты, частые обновления |
| Blue-Green | Два сервера, переключение | Высоконагруженные (без простоя) |
| Canary | Постепенный rollout на % | Рискованные обновления |
Стек технологий деплоя:
- Git — версионирование кода
- Docker — контейнеризация (одинаковая среда везде)
- Nginx — веб-сервер (принимает запросы)
- Gunicorn/uWSGI — WSGI-сервер для Python
- Supervisor — управление процессами
- Let's Encrypt — SSL-сертификаты
Частота деплоя:
| Тип проекта | Частота |
|---|---|
| Лендинг | 1-2 раза после запуска |
| Корпоративный сайт | 1-2 раза в месяц |
| Интернет-магазин | 2-4 раза в месяц |
| SaaS-сервис | Несколько раз в день |
Риски при деплое:
- Сайт "упал" после обновления (откатываем через git)
- Потеря данных (бэкап перед деплоем)
- Баги на продакшене (тестируем на staging)
- Долгий простой (используем blue-green)
Как мы делаем деплой в WEBVISUAL:
- Тестируем локально (все тесты зелёные)
- Деплоим на staging-сервер (копия продакшена)
- Тестируем на staging (ручное + автотесты)
- Деплоим на продакшен в нерабочее время (ночь)
- Проверяем работоспособность
- Мониторим первые 24 часа
Откат (rollback):
- Если что-то сломалось — откатываем к предыдущей версии
- Время отката: 1-5 минут (через git)
- Данные БД — из бэкапа (если изменились)
Реальный кейс: Клиент — SaaS-сервис. Было: ручной деплой раз в месяц (стресс, баги).
- Внедрили: CI/CD через GitHub Actions
- Результат: деплой 5-10 раз в день, без стресса
- Баги на продакшене: снизились на 80%