От Preview к Live: что проверить перед публикацией

Представьте, что вы подготовили для мастерской сайт с формой заявки на ремонт. Страница открывается, фотографии на месте, после отправки появляется «Спасибо», и можно делиться ссылкой с клиентами. Но первая же заявка не находится в кабинете администратора. Если проследить её путь, может выясниться, что форма всё это время обращалась к тестовому API, а кабинет уже показывает рабочие данные. Заявка сохранилась, только искать её нужно в другой среде.

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

В Agnostic для работы есть окружения Live, Preview и Dev. Live обычно используется для рабочей версии, а Preview и Dev позволяют проверять изменения перед её обновлением. При этом в каждой из этих сред приложение может получить публичный адрес. Если вы дали кому-то ссылку на Preview, само название среды не ограничивает ему доступ, поэтому закрытый просмотр и защиту данных нужно настраивать в приложении.

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

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

Допустим, после сборки вы заметили неудачную подпись кнопки и исправили её в редакторе. Подготовленные файлы от этой правки не изменились, поэтому при публикации той сборки посетитель увидит старую подпись. Чтобы не путаться, сохраните идентификатор версии и запомните один заметный признак изменения. Тогда по открытому сайту и истории выпуска можно проверить, совпадает ли опубликованный результат с тем, который вы собирались показать.

Если у приложения есть и Web, и API, обновление может затронуть обе части. Например, новая форма отправляет дополнительное поле, а прежний сервер его ещё не принимает. Кроме того, у некоторых пользователей остаются открыты вкладки со старой формой. При таком изменении удобно сначала подготовить API к обоим вариантам запроса, затем выпустить новый сайт и уже позже убрать старую поддержку. Так вы учитываете период, когда посетители пользуются разными версиями интерфейса.

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

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

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

На этом этапе полезно сверить подключения. Сайт должен обращаться к своему API, а сервер — к данным выбранного окружения. Служебный runtime-токен хранится на backend и не попадает в браузер посетителя. Если ключ уже оказался в клиентском коде, его нужно не только убрать из файла, но и отдельно отозвать или заменить по правилам сервиса: загруженную пользователем копию сайта одной правкой на сервере не отозвать.

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

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

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

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

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

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

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

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

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

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

Когда проверка закончена, выберите окружение выпуска в меню проекта. Для рабочей версии сверьте Live, затем откройте раздел «Приложения» и карточку нужного Web или API. Начать публикацию можно и из раздела кода. Перед запуском сохраните открытые изменения в черновик, чтобы правка, которую вы ожидаете увидеть на сайте, действительно вошла в выбранную версию.

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

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

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

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

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

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

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

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

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