CI/CD без DevOps — это набор автоматических шагов, которые берут репозиторий в GitHub и выкладывают сайт на хостинг по SFTP без постоянного ручного вмешательства. Такой подход экономит время владельцу кафе, салона или интернет‑магазина и уменьшает риск ошибок при обновлениях.
Быстрый запуск для лендинга кафе в Минске: что это даёт
Сценарий: владелец кафе в Минске правит меню в markdown в репозитории, пушит изменения и ожидает, что сайт обновится автоматически вечером перед завтраком клиентов.
Как сделать:
- Создать репозиторий с файлам сайта (HTML/CSS/готовая сборка или статический генератор).
- Добавить секреты в GitHub: SFTP_HOST, SFTP_USER, SFTP_PASSWORD, TARGET_PATH.
- Включить GitHub Actions с простым workflow: checkout → сборка (если требуется) → загрузка файлов по SFTP. Можно использовать готовое действие для SFTP или rsync‑подобный шаг.
- Настроить работу по пушу в ветку main или по тегу. Тестировать на отдельной папке перед заменой продакшн‑файлов.
Совет: храните сборку в артефактах Actions и прогоняйте короткий smoke‑тест (проверка статуса 200) перед замещением файлов.
Интернет‑магазин в Гродно: деплой с миграцией ассетов и откатом
Сценарий: небольшой магазин в Гродно обновляет шаблон и медиафайлы. Нужен автоматический деплой и возможность отката, если на сайте появились ошибки.
Как сделать:
- Соберите билд локально или в CI и загружайте в целевую папку вида /var/www/shop/releases/YYYYMMDD.
- После загрузки переключайте символическую ссылку current на новую релиз‑папку. Это упрощает откат — достаточно вернуть ссылку на предыдущую папку.
- Для больших медиа используйте S3‑совместимое хранилище и сохраняйте только ссылки в релизе; это уменьшит время деплоя. Полезно посмотреть варианты хранения и бэкапов для медиа.
Совет: перед переключением ссылки выполняйте быстрый health‑check на главный URL и только при успехе меняйте current. Если health‑check падает, автоматически откатывайте ссылку на предыдущую версию.
Салон красоты в Мозыре: автоматизация обновлений виджетов и резервное копирование
Сценарий: салон красоты добавил виджет записи и хочет, чтобы после обновления сайта резервная копия создавалась автоматически.
Как сделать:
- Добавьте шаг в workflow, который создаёт архив текущей версии сайта и сохраняет его как артефакт Actions или загружает на удалённый бэкап‑сервер перед деплоем.
- После деплоя запускайте краткий тест функциональности виджета (POST запрос к эндпойнту записи с тестовыми данными без реальной записи клиентов).
- Настройте уведомления в канал администратора (email, Telegram) о результате деплоя и о ссылке на бэкап.
Совет: для резервных копий используйте автоматические бэкапы на VPS или облаке, это снижает риск потери данных при некорректном деплое.
Типичные ошибки
- Хранение паролей в репозитории вместо секретов GitHub.
- Прямая перезапись продакшн‑папки без артефактов и без механизма отката.
- Отсутствие health‑check после деплоя — откат становится ручным и долгим.
- Загрузка больших медиа через SFTP в процессе каждого деплоя — деплой занимает слишком много времени.
- Отсутствие мониторинга состояния сайта после обновления — проблемы обнаруживаются клиентами.
Полезные ссылки: пошаговый план миграции на хостинг в Беларуси без простоя (https://inrb.by/pereezd-proekta-na-khosting-v-belarusi-bez-prostoya), мониторинг сайта без DevOps для малого бизнеса (https://inrb.by/monitoring-sayta-bez-devops-dlya-malogo-biznesa).
3 шага, которые можно сделать на неделе:
- Создать тестовый репозиторий и прописать минимальный workflow для копирования файлов по SFTP.
- Добавить секреты в GitHub и настроить деплой в тестовую папку на хостинге.
- Внедрить простой health‑check и автоматический откат через символические ссылки или версии релизов.