Деплой сайта: как выложить в интернет без сбоев

Что такое деплой простыми словами

Ты сделал сайт. На компе он работает идеально: красивый, быстрый, всё кликается. Одна беда. Его не видит ни одна живая душа, кроме тебя. Чтобы сайт увидел мир, проект надо выложить в интернет. Вот этот переезд и называется деплой Деплой (deploy) - публикация проекта на сервере в интернете, чтобы им могли пользоваться настоящие люди, а не только ты на своём компе. .

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

Хороший деплой - это всегда второй способ. Пользователь не должен заметить, что ты вообще что-то трогал. Сайт работал - и работает дальше, просто стал лучше.

Зачем вайбкодеру разбираться в публикации сайта

Ты вайбкодер. Код за тебя пишет агент. Но кнопку «опубликовать» в финале нажимаешь ты. И за упавший сайт отвечать тоже тебе. Когда ты понимаешь, как устроен деплой, ты:

• выкатываешь обновления так, что посетители ничего не замечают;
• не светишь свои пароли и ключи на весь интернет (самая частая и самая дорогая ошибка новичка);
• умеешь откатиться назад за секунды, а не строчишь агенту в панике «верни как было!!!»;
• понимаешь, что прячется за страшными словами rollback, health check, staging - и можешь спокойно попросить агента всё это настроить.

Разница между «я выложил сайт, и он лежит» и «я выложил сайт, и всем норм» почти всегда сводится к четырём вещам: как выкатываешь, где хранишь секреты, как проверяешь что живо и есть ли план отката. Идём по порядку.

Четыре опоры спокойного деплоя

1. Как выкатывать обновления без падений

Крошечный сайт на одном сервере? Тогда всё просто: новая версия заменяет старую, и привет. Но стоит проекту подрасти - и появляются хитрые способы обновляться так, чтобы сайт ни на секунду не лёг. Вот три главных, от простого к надёжному.

• Rolling Rolling deployment - обновление по очереди: серверы переключаются на новую версию один за другим, а не все разом. Сайт всё время работает. (по очереди). У тебя несколько копий сайта. Обновляешь их не разом, а по одной: пока одна переезжает на новую версию, остальные держат посетителей. Никто не остаётся без сайта.
• Blue-green Blue-green deployment - две одинаковые площадки: на одной работает старая версия, рядом готовится новая. В нужный момент трафик мгновенно переключают на новую. (две площадки). Две одинаковые копии: «синяя» работает прямо сейчас, «зелёная» стоит наготове с новой версией. Проверил зелёную - щёлкнул рубильником, и весь трафик ушёл туда. Что-то не так? Щёлкнул обратно - мгновенный откат.
• Canary Canary deployment - новую версию сначала показывают маленькой части посетителей (например 5%). Если у них всё хорошо - постепенно открывают остальным. (канарейка). Новую версию сначала видят только 5% посетителей. Им хорошо - открываешь половине, потом всем. Название - от шахтёрских канареек: если что-то не так, ты узнаёшь это на маленькой группе, а не на всех сразу.

2. Где хранить секреты: переменные окружения, не код

Это самое важное правило урока. У проекта есть секреты Секреты - пароли, ключи к базам данных, токены платёжных сервисов и прочие данные, по которым можно зайти в твой проект. Их нельзя показывать никому. : пароль от базы данных, ключ к платёжке, токен бота. Если они написаны прямо в коде, то стоит коду уехать в интернет (а он уезжает - например, на GitHub), секреты уедут вместе с ним и станут видны кому угодно.

Правильно - хранить их в переменных окружения Переменные окружения (environment variables) - настройки, которые задаются отдельно от кода, прямо на сервере. Код берёт их оттуда, но в самом коде их нет. . Это как ключи от квартиры: они не нарисованы краской на двери, а лежат у тебя в кармане. Код знает: «ключ где-то есть, возьму в нужный момент» - но самого ключа в коде нет.

3. Health-check: служебная страница «ты живой?»

Health-check Health-check - простой адрес на сайте (например /health), который отвечает «всё ок». По нему сервер автоматически проверяет, жив ли проект. - это крошечная служебная страничка, например по адресу /health, которая просто отвечает «у меня всё в порядке». Сам ты на неё никогда не зайдёшь. Она для машин, не для людей.

А зачем она вообще? Сервер раз в полминуты дёргает эту страничку и спрашивает: «жив?». Отвечает «да» - отлично, идём дальше. Молчит или ругается - сервер понимает, что проект завис, и может сам его перезапустить или перестать пускать на него людей. Это как пульс у пациента: монитор пищит ровно - все спокойны; сигнал пропал - прибежала медсестра.

4. План отката: кнопка «верни как было»

Даже у профи случается: выкатил обновление, а оно сломало сайт. Разница между профи и новичком ровно одна: у профи есть кнопка «назад». Это и есть откат Откат (rollback) - быстрый возврат к предыдущей рабочей версии проекта, если новая оказалась сломанной. (rollback).

На нормальных площадках откат - это буквально одна кнопка или одна команда: «вернуть предыдущую версию». Старая рабочая сборка всегда лежит сохранённой. Поэтому правильный ход мыслей при деплое - не «лишь бы взлетело», а «если не взлетит - как я верну всё за 10 секунд?».

Хороший деплой против плохого: сравнение

Staging Staging - тестовая копия сайта, точная как боевая, но для пользователей закрытая. На ней проверяют обновления перед публикацией. в этом списке - отдельный герой. Это копия твоего сайта, на которой ты сначала всё проверяешь, и только потом катишь на боевую. Дёшево, скучно и спасает вагон нервов.

Пример из жизни: как утекает токен бота

Ты сделал агентом сайт-визитку с формой записи. Форма шлёт заявки тебе в Telegram через бота - для этого нужен токен бота. Агент по-быстрому вписал токен прямо в код, ты обрадовался, что всё работает, и запушил проект на публичный GitHub. К вечеру твой бот рассылает спам незнакомым людям, а сайт при каждом обновлении на пару минут теряет форму, потому что катишь ты прямо на боевую версию. Весело, да?

Что пошло не так:

1. Токен жил в коде и утёк в открытый репозиторий - боты подобрали его за минуты.
2. Не было health-check и staging - обновления проверялись прямо на живом сайте.
3. Не было плана отката - когда форма сломалась, вернуть рабочую версию было нечем.

А вот как сделал бы понимающий вайбкодер. Просто грамотно поставил бы задачу агенту.

Помоги подготовить мой проект к публикации в интернете. Сделай по шагам:

Найди в коде все секреты - токены, пароли, ключи. Вынеси их в переменные окружения и создай файл-пример env с пустыми значениями. Убедись, что настоящие секреты НЕ попадают в репозиторий, добавь их в gitignore.
Добавь простой health-check по адресу /health, который отвечает статусом ок.
Объясни простыми словами, как на моей площадке (я использую Vercel) откатиться на предыдущую версию, если новая сломается.
Перед тем как сказать, что всё готово, пройдись по короткому чек-листу готовности к публикации и покажи мне его галочками.
Каждый шаг показывай отдельно и жди моего ок, прежде чем идти дальше.

Чек-лист готовности к публикации: 60 секунд перед кнопкой

Прежде чем нажать «опубликовать», пробеги глазами. Это упрощённая версия профессионального чек-листа из скилла deployment-patterns:

1. Тесты прошли? Если агент делал тесты - они зелёные?
2. Секретов в коде нет? Ни одного пароля, ключа или токена прямо в файлах.
3. Health-check отвечает? Зайди на /health - там «ок»?
4. Знаешь, как откатиться? Не «разберусь, если что», а прямо сейчас знаешь команду или кнопку.
5. Проверил на staging? Обновление сначала пожило на тестовой копии, а не сразу на боевой.
6. Время выбрано с умом? Не вечер пятницы и не за пять минут до важной встречи.

Пиксельная памятка

Частые ошибки новичка при деплое

• Зашить секреты в код. Они утекут вместе с проектом. Только переменные окружения, без исключений.
• Катить сразу на боевую. Сначала staging, потом мир. Иначе ты тестируешь на живых людях.
• Не иметь плана отката. «Если сломается - разберусь» - это не план. План - это кнопка «назад», которую ты знаешь заранее.
• Игнорировать health-check. Без него о падении ты узнаёшь последним - от злых пользователей.
• Деплоить в пятницу вечером. Старая инженерная мудрость: сломается ровно тогда, когда чинить уже некому.
• Менять базу данных «навсегда» в спешке. Удалил данные новой версией - откат кода их уже не вернёт.