Laravel Cloud: отдельный стенд для PR ещё не копия production
Отдельный preview-стенд Laravel Cloud нужно принимать по ресурсам и внешним действиям, а не по наличию ссылки в pull request. Проверьте базу, файлы, кеш и переменные: настройки могут оставлять их общими с целевым окружением. Спящее вычисление также не означает, что проект больше не имеет расходов или что стенд повторяет production.
Что обсуждал сентябрьский разбор
Материал Laravel от 28 сентября 2026 года посвящён сочетанию preview environments и scale to zero. Он описывает развёрнутую версию приложения для PR и автоматизацию её жизненного цикла. Это дата разбора, а не доказательство, что сама возможность preview впервые появилась в сентябре.
Для команды такой стенд удобен как место проверки конкретного изменения. Но похожая страница ещё не означает одинаковых данных, очередей и инфраструктуры с рабочей системой. До демонстрации заказчику полезно записать, что стенд действительно подтверждает, а что остаётся отдельной приёмкой.
Какие границы задаёт автоматизация
Документация Laravel Cloud разделяет создание новых ресурсов, использование общих и работу без некоторых из них. В частности, общая база означает, что изменения данных затронут целевую среду. Удаление preview не отменяет уже сделанное в такой базе.
Возьмём вымышленный PR с новой формой заявки. Для проверки нужен тестовый пользователь, сохранение заявки и отображение результата. Платёж, сообщение настоящему клиенту и обработка рабочих документов в этот сценарий не входят. Ресурсы подбираются под эту границу, а не копируются без разбора.
| Ресурс или действие учебного стенда | Отдельный вариант | Если используется общий | Что принимает команда |
|---|---|---|---|
| База заявок | Разрешённые учебные записи в отдельной базе | Проверка может изменить чужие рабочие данные | Известен источник и место каждой записи |
| Файлы формы | Отдельное хранилище тестовых вложений | Файлы могут остаться после удаления preview | Понятны границы доступа и очистки |
| Кеш и состояние | Согласованное разделение тестовых данных | Нужна проверка пространства ключей и клиентов | Стенды не подменяют состояние друг друга |
| Письма и внешние API | Учебные получатели и тестовые подключения | Обычная форма способна вызвать рабочее действие | Ни одна тестовая операция не уходит клиенту |
| Переменные окружения | Полный проверенный набор для preview | Старые правила могут переносить лишние секреты | Значения соответствуют именно учебному контуру |
Почему переменные нужно проверить отдельно
Текущая документация описывает отдельный набор переменных автоматизации, а для автоматизаций до 13 июля 2026 года предупреждает о прежней модели наследования. Поэтому не переносите утверждение о новых настройках на любую старую конфигурацию. Проверять нужно действующее правило конкретного проекта.
Не публикуйте значения секретов в обсуждении PR ради сравнения. Достаточно карты назначений: какая переменная включает рабочую отправку, какое подключение ведёт к учебным данным и кто это проверил. Наличие отдельной базы не исправит ошибочный ключ внешнего сервиса.
Два PR не должны незаметно менять одну проверку
Если разные ветки используют один ресурс, зафиксируйте допустимые пересечения. Иначе один рецензент получит результат, созданный другим стендом, и примет его за следствие своего изменения. В учебном примере каждая заявка должна относиться к известному окружению.
Сравнивая preview с production, перечислите отличия, которые влияют на вывод: объём данных, подключения, конфигурация и фоновые задачи. Тестовый успех подтверждает выбранный сценарий, но не производительность под рабочей нагрузкой. Полную копию нельзя объявить полученной только из-за одинаковой версии кода.
Сон и удаление — разные части жизненного цикла
Scale to zero относится к вычислительным ресурсам там, где механизм поддерживается. Для оценки расходов рассматривайте также созданные и общие ресурсы и правила их использования. Мы не переносим денежный пример чужого стенда на любую компанию и не обещаем полную бесплатность preview.
После закрытия PR проверьте выбранную настройку удаления и состав ресурсов, созданных автоматизацией. Общие файлы и данные не следует считать автоматически очищенными. Назначьте владельца оставшихся ресурсов и понятный срок разбора, чтобы временные стенды не становились забытыми постоянными средами.
- Опишите сценарий PR и исключённые рабочие действия.
- Составьте карту базы, файлов, кеша и внешних подключений.
- Проверьте набор переменных и возраст правил автоматизации.
- Выполните разрешённую учебную проверку в изолированной среде.
- Проверьте возможное пересечение с другим preview.
- Зафиксируйте отличия от production и границы результата.
- Проверьте сон, удаление и судьбу общих ресурсов отдельно.
Для сопровождения серверной среды передайте карту ресурсов и очистки. В разработке веб-приложения отделите пользовательский сценарий от инфраструктурной приёмки, а при доработке процесса закрепите проверку внешних действий. В рамках статьи стенды не создавались, облачные ресурсы не заказывались и настройки проекта не менялись.
Вопросы и ответы
Что проверять в Laravel Cloud preview environments?
Проверьте ресурсы, переменные и внешние действия нужного сценария. Отдельная ссылка сама по себе не подтверждает изоляцию данных или эквивалентность production.
Scale to zero делает preview полностью бесплатным?
Такой вывод нельзя сделать только из сна вычислительного ресурса. Для оценки нужны состав остальных ресурсов и действующие правила их использования.
Можно ли использовать общее хранилище Laravel Cloud для preview?
Документация предусматривает такой вариант, но его последствия нужно принять явно. Общие файлы могут сохраняться после удаления стенда, а доступ и очистка требуют отдельной проверки.