Год назад я сидела перед пустым репозиторием и думала: «Ну, сейчас я точно сломаю всё к чёртовой матери». Задача была простой — настроить автоматический деплой после каждого push в main. Звучит не сложно, правда?

Почему я вообще туда полезла

Исторически так сложилось, что я работала с фрилансерами. Они деплоили вручную — заходили на сервер, делали git pull, перезапускали Node.js. Работало. Но в три часа ночи, когда что-то падало, никто не был на связи. А я просыпалась от звонка клиента с вопросом: «А почему сайт не открывается?»

Мне это надоело. Я решила: если не могу нанять DevOps-инженера за адекватные деньги — сделаю сама. Плохо, но сделаю.

Что я выбрала и почему

GitHub Actions. Не потому что он лучший, а потому что он уже был. Мой код уже лежал на GitHub, значит лишних интеграций не надо.

Первый workflow я скопировала с чужого репозитория. Это была ошибка. Чужой workflow был для другого стека, другой структуры проекта. Мне потребовалось три дня, чтобы понять, почему deploy step падает с непонятной ошибкой.

Чек-лист, который я составила для себя

  • Понять стек — Node.js? Python? Статика? От этого зависит весь pipeline
  • Понять окружение — development, staging, production. Это три разные конфигурации
  • Записывать каждую ошибку — каждая ошибка стала частью чек-листа
  • Автоматизировать только после стабильного ручного процесса — не автоматизируй то, что ещё не работает вручную

Что в итоге получилось

Запуск CI/CD занял неделю. Первый автоматический деплой случился в три часа ночи — но в этот раз я спала. Система сама протестировала код, сама задеплоила, сама написала мне в Telegram: «Всё ок».

Мораль: DevOps — это не про серверы и не про код. Это про то, чтобы освободить голову для реальной работы. Каждый ручной шаг в деплое — это потенциальная ошибка, которую вы совершите в три часа ночи.