Тестовый сервер, деплой и релиз простыми словами: как обновления попадают на рабочий сайт без поломок

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

Что такое тестовый сервер и зачем он заказчику?

Это второй экземпляр проекта на отдельном адресе, например test.вашсайт.ru, закрытый паролем. На нём работает тот же код, что пойдёт к клиентам, но с безопасными данными. Заказчику он даёт возможность увидеть и потрогать результат до выкладки, а не узнавать о проблеме из жалоб покупателей.

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

Что даёт тестовый сервер на практике:

• Приёмка по живой ссылке. Вы проходите сценарий сами: оформляете заказ, меняете статус, выгружаете отчёт. Замечания пишете по конкретному экрану.
• Согласование с коллегами. Ссылку можно отправить бухгалтеру, руководителю отдела продаж или юристу, не выкладывая черновик в интернет.
• Проверка интеграций без риска. Обмен с CRM, 1С или платёжной системой гоняют в тестовом режиме, не создавая настоящих сделок и платежей.
• Спокойная приёмка по договору. В наших договорах на подписание акта или мотивированный отказ у заказчика 5 рабочих дней. Проверять удобно именно на тестовой копии, пока клиенты работают со старой версией.

	Dev (разработка)	Stage (тестовая копия)	Prod (боевой сервер)
Где находится	На компьютере разработчика или в его личной песочнице	На отдельном сервере или поддомене вроде test.example.ru	На сервере, куда указывает ваш домен
Кто туда ходит	Только разработчик	Команда, заказчик, тестировщик	Клиенты и сотрудники
Какие данные	Выдуманные, несколько записей	Демонстрационные или обезличенные, близкие по объёму к настоящим	Настоящие заказы, клиенты, платежи
Оплата и письма	Отключены	Тестовый режим платёжной системы, письма только на адреса команды	Настоящие
Что можно ломать	Всё	Можно, для этого он и нужен	Ничего: любая ошибка видна клиентам
Видят ли поисковики	Нет	Нет: закрыт паролем и запретом индексации	Да

Чем dev, stage и prod отличаются?

Это три среды, через которые проходит каждое изменение. Dev — рабочее место разработчика, где код пишут и ломают. Stage — тестовая копия, максимально похожая на боевую, где изменения проверяет команда и заказчик. Prod — боевой сервер, с которым работают клиенты. Код движется только в одну сторону: dev, stage, prod.

В разговорах встречаются и другие названия: «тестовый стенд», «препрод», «staging», «песочница». Небольшим проектам часто хватает двух сред — компьютера разработчика и боевого сервера с временным закрытым адресом для показа. Для магазина, личного кабинета или CRM полноценная stage-копия нужна почти всегда.

Главное требование к stage — сходство с prod. Если на тестовом сервере другая версия PHP или Node.js, другая база или нет настоящего объёма каталога, проверка там мало что доказывает: «на тесте работало» превращается в «на бою сломалось».

Что проверять заказчику по ссылке на тестовую версию?

Не дизайн целиком, а то, что изменилось в этом выпуске, и два-три главных сценария, которые не должны были сломаться. Попросите у разработчика короткий список изменений к каждой ссылке — по нему проверка занимает 15–30 минут.

Чек-лист заказчика для тестовой версии:

1. Список изменений. Каждый пункт из него вы нашли и увидели своими глазами. Если пункт не виден, это вопрос к разработчику, а не повод искать самому.
2. Главный путь клиента. Заявка, заказ, запись или вход в кабинет проходят от начала до конца, а не до кнопки «Отправить».
3. Телефон. Новый блок или экран открыт с вашего смартфона, а не только в окне браузера на компьютере.
4. Роли. Если в сервисе есть менеджер, бухгалтер и клиент, зайдите под каждой ролью: новые кнопки часто видны не тем людям.
5. Тексты, цены, реквизиты. Их сверяет только заказчик: разработчик не знает, что цена устарела.
6. Старые функции рядом. Поменяли карточку товара — проверьте, что корзина и фильтр по-прежнему работают.

Замечания удобнее давать одной задачей со ссылкой на страницу, описанием шагов и скриншотом. Как формулировать правки, чтобы их не пришлось переспрашивать, мы разбирали в статье о правках по дизайну и сайту. Какие проверки разработчик делает сам до того, как пришлёт ссылку, — в статье о видах тестирования.

Почему нельзя править прямо на рабочем сайте?

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

Типичные последствия «быстрой правки на сервере»:

• опечатка в одном символе шаблона кладёт всю страницу, и до исправления посетители видят ошибку 500;
• через месяц очередная выкладка из репозитория затирает ручную правку, и проблема возвращается, а никто не помнит почему;
• два человека правят один файл одновременно, и изменения одного пропадают;
• новый подрядчик получает код из репозитория, который не совпадает с тем, что реально работает на сервере.

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

Что такое деплой и релиз?

Деплой (от английского deploy — развернуть) — техническая операция: собранную версию кода устанавливают на сервер и запускают. Релиз — событие для пользователей: новая функция стала им доступна. Обычно это происходит одновременно, но их можно и разнести: код выложить во вторник, а функцию включить в четверг после обучения сотрудников.

Как выглядит деплой в аккуратном проекте:

1. Изменения приняты на тестовой копии и влиты в основную ветку репозитория.
2. Снята резервная копия базы данных и загруженных файлов боевого сервера.
3. Новая версия собирается из репозитория, а не копируется с чьего-то компьютера.
4. Если меняется структура базы, применяется миграция — скрипт, который добавляет нужные поля и таблицы.
5. Сервер переключается на новую версию, разработчик проходит главные сценарии уже на бою.
6. В журнале изменений или в задаче записано, какая версия выложена и когда.

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

Для заказчика полезно договориться об окне обновлений — времени, когда выкладка безопасна. Для магазина это не вечер пятницы и не день распродажи, для B2B-кабинета — не конец месяца, когда бухгалтерия закрывает период. Хорошее окно — рабочий день, первая половина, когда на связи и разработчик, и человек с вашей стороны.

Способ	Как работает	Простой для посетителей	Кому подходит
Залить файлы поверх	Новые файлы копируют на сервер прямо в рабочую папку	Секунды или минуты, пока часть файлов старая, а часть новая	Статичной странице без форм и базы
Атомарное переключение	Новая версия собирается в соседней папке, затем сервер одной операцией начинает смотреть на неё	Практически нет; откат — переключение обратно	Сайтам и магазинам на своём сервере
Две копии (blue-green)	Работают две одинаковые среды, трафик переводят со старой на новую	Нет; старая копия ждёт на случай отката	Сервисам, где минута простоя стоит денег
Постепенный выпуск	Новую версию сначала получает небольшая доля пользователей, затем все	Нет; ошибку замечают на малой доле	Крупным сервисам и мобильным приложениям

Как выкладывают обновления без простоя?

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

Самое тонкое место — база данных. Код откатить просто, а удалённую колонку или переименованное поле — нет. Поэтому изменения базы делают в два шага: сначала добавляют новое, не трогая старое, выкладывают код, который умеет работать с обоими вариантами, и только через одну-две выкладки убирают лишнее. Такие миграции называют аддитивными.

Так устроены и наши собственные продукты. На сайте студии и клиентском портале выкладка идёт без простоя, миграции базы только добавляют поля и таблицы, а копии базы снимаются по расписанию. В ITSM-системе «КРОМ» миграции также выполняются без остановки сервиса, а в ИИ-ассистенте юриста «Довод» ночные резервные копии хранятся с ротацией, а сторож проверяет состояние сервиса каждые 5 минут.

Не каждому проекту нужен blue-green с двумя серверами. Сайту компании с десятком страниц достаточно атомарного переключения: оно не требует второго сервера и даёт быстрый откат. Две полные копии окупаются там, где минута недоступности означает сорванные заказы и звонки в поддержку.

Что делать, если после релиза что-то сломалось?

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

Порядок действий, который стоит согласовать с подрядчиком заранее:

1. Кто решает. Названо, кто со стороны заказчика может сказать «откатывайте» и кто со стороны разработчика это делает.
2. Как откатывают код. Возврат к предыдущей версии одной командой или переключением, без ручного копирования файлов.
3. Что с базой. Если релиз менял данные, есть копия, снятая непосредственно перед выкладкой, и понятно, какие новые заказы за это время придётся перенести вручную.
4. Как сообщить клиентам. Временное объявление на сайте или в рассылке, если сбой затронул оплату или доставку.
5. Разбор после. Ошибку воспроизводят на тестовой копии, исправляют и добавляют проверку, чтобы она не повторилась.

Резервная копия перед выкладкой — не формальность. Бэкап, который делается раз в сутки ночью, к обеду уже не содержит утренних заказов. Если выкладка меняет данные, свежая копия снимается прямо перед ней. Ошибка, возникшая по вине исполнителя и найденная в первые 30 календарных дней после подписания акта, исправляется бесплатно по гарантии; дальнейшие обновления обычно идут в рамках поддержки.

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

Можно ли копировать реальные данные клиентов на тест?

Без необходимости — нет. Закон о персональных данных требует, чтобы обработка ограничивалась заранее определёнными целями, а объём данных им соответствовал и не был избыточным. Полная копия клиентской базы на тестовом сервере, куда ходят подрядчики и стажёры, этим требованиям обычно не отвечает. На тесте нужны обезличенные или выдуманные данные.

Опора — статья 5 Федерального закона «О персональных данных» (152-ФЗ): части 2 и 5 требуют конкретных целей и запрещают избыточные данные, часть 7 — уничтожать или обезличивать данные, когда цель достигнута. Если подрядчик работает с данными ваших клиентов, это поручение обработки по ч. 3 ст. 6 того же закона, и его нужно оформить в договоре.

Как это решают на практике:

• Демо-данные. Скрипт заполняет тестовую базу выдуманными клиентами и заказами в нужном объёме. Для большинства проверок этого хватает.
• Обезличенная копия. Если ошибка воспроизводится только на настоящих данных, копию базы прогоняют через скрипт, который заменяет имена, телефоны, адреса и почты, а уже потом переносят на тест.
• Тестовые режимы сервисов. Платёжная система, рассылки и SMS на тестовом сервере работают в тестовом режиме или отключены, чтобы клиенту не пришло письмо о несуществующем заказе.
• Закрытый доступ. Тестовый адрес защищён паролем и закрыт от индексации, список тех, у кого есть вход, известен заказчику.

Подробнее о том, где должны храниться данные сайта и что требует закон о локализации, — в статье о хранении данных и 152-ФЗ.

Когда отдельный тестовый сервер не нужен и какие ошибки встречаются?

Постоянная stage-среда избыточна для лендинга, сайта-визитки и страницы под проверку гипотезы: там хватит закрытого временного адреса для показа и резервной копии перед публикацией. Тестовая копия становится обязательной, когда есть база данных, оплата, личные кабинеты, интеграции и обновления чаще раза в месяц.

Ошибки, с которыми приходят на поддержку:

• тестовый сервер открыт всем и попал в поиск — клиенты находят черновые цены;
• на тесте рабочие ключи платёжной системы, и проверочный заказ списал деньги с настоящей карты;
• с тестового сервера уходят письма настоящим клиентам;
• тестовая копия годами не обновлялась и уже не похожа на боевую;
• выкладка без копии базы, и откатить код можно, а данные — нет;
• обновления выкладывают в пятницу вечером или в день распродажи;
• доступ к серверу есть у одного человека, и откатиться без него некому;
• на тест скопирована вся клиентская база «на всякий случай».

Сколько стоит выкладка с тестовой версией и что входит в работу студии?

Отдельной строкой в прайсе этого нет: показ на закрытом адресе, проверка и публикация — часть разработки. Ориентиры по тарифам — лендинг от 24 000 ₽, корпоративный сайт от 56 000 ₽, интернет-магазин от 104 000 ₽, веб-приложение от 160 000 ₽. Нужна ли постоянная stage-копия и сколько она добавит, считаем после брифа.

Что важно знать заранее:

• хостинг и сервер для тестовой копии в цену тарифа не входят и оплачиваются отдельно, так же как основной хостинг;
• число раундов правок и на каких этапах они проходят, указано в описании тарифа; на подписание акта у заказчика 5 рабочих дней, гарантия на ошибки по вине исполнителя — 30 календарных дней с даты акта;
• регулярные обновления после запуска удобно вести в рамках поддержки и развития — от 7 900 ₽/мес: тогда выкладка, копии и откат становятся рутиной, а не событием.

Если проект только начинается, порядок сред, выкладки и отката стоит обсудить на старте заказной разработки, а не после первой аварии. Как подготовить сам день первой публикации на домене, — в отдельной статье о запуске сайта.

Короткие ответы на частые вопросы

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

Это копия вашего сайта или сервиса на отдельном адресе, закрытая от посторонних. На ней разработчик показывает готовые изменения, а заказчик проверяет их до того, как их увидят клиенты.

Чем деплой отличается от релиза?

Деплой — техническая операция: новая версия кода установлена на сервер. Релиз — момент, когда изменения стали доступны пользователям. Часто они совпадают, но функцию можно выложить заранее и включить позже.

Что такое prod или продакшн?

Так разработчики называют боевую среду — сервер, на котором работает сайт для настоящих клиентов. «Выложить на прод» значит установить обновление на рабочий сайт.

Как откатить неудачный релиз?

Вернуть предыдущую версию кода тем же способом, каким выкладывали новую, а если релиз менял базу данных — восстановить её из копии, снятой перед выкладкой. Порядок отката стоит проверить заранее, а не в момент аварии.

Нужен ли тестовый сервер для лендинга?

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

Услуги и кейсы по теме: поддержка сайта от 7 900 ₽/мес · заказная разработка · кейс: сайт студии и клиентский кабинет · цены и сроки