Тестовое окружение для того же выпуска

Упакованный кандидат ещё не обязан становиться действующим сайтом. Для просмотра используем staging.example.com: отдельное окружение, где можно проверить страницы и старые адреса до переключения основного домена. Слово staging означает место проверки, а не обязательный новый способ сборки. В нашем примере туда поступает тот же архив, который затем рассматривается для production.

Разделим два вида отличий. Содержание статических файлов должно совпадать с кандидатом. Корень сервера, сертификат, пароль доступа и журнал запросов относятся к окружению и могут различаться. Если повторно генерировать статьи специально для staging, сравнение с производственным артефактом потребует дополнительного объяснения. Начнём с более простой модели: один результат, два изолированных места размещения.

Изоляция каталога и имени

Корень тестового сайта зададим как /srv/release-lab-staging/current/public. Каталоги выпуска расположены под отдельным префиксом. Это уменьшает вероятность, что загрузка кандидата случайно затронет example.com. У имени staging своя DNS-запись и свой серверный блок. Общий IP допустим, но он не заменяет разграничение корней. Любой путь, который собирается изменить сценарий доставки, должен начинаться с выбранного префикса окружения.

Предположим, что на основном сайте работает r1, а на staging выбран r2. Такая ситуация нормальна. Паспорт в каталоге и публичный health.json позволяют установить её явно. Если и там и там найден r1, сначала выясняют, какой архив доставлен и куда указывает current. Исправлять текст статьи ради этого симптома не нужно: ошибка может находиться в выборе каталога, а не в содержимом артефакта.

Защита доступа относится к серверу

Черновой сайт закрываем серверной аутентификацией. Директива robots.txt управляет поведением поддерживающих её роботов, но не проверяет право открыть страницу. Даже запрет индексации не скрывает данные от пользователя, который знает URL. Наш staging не содержит приватных пользовательских данных, однако закрытый доступ всё равно полезен: кандидат не становится вторым публичным экземпляром библиотеки. Модуль базовой аутентификации Nginx.

# Фрагмент отдельного TLS-сервера staging.example.com.
root /srv/release-lab-staging/current/public;
auth_basic "release-lab staging";
auth_basic_user_file /etc/nginx/release-lab-staging.htpasswd;
add_header X-Robots-Tag "noindex" always;
add_header Cache-Control "private, no-store" always;

location ~ \.php$ {
    types { text/html php; }
    try_files $uri =404;
}
location / { try_files $uri $uri/ =404; }
error_page 404 /404.html;
location = /404.html { internal; }
location = /health.json {
    add_header Cache-Control "private, no-store" always;
    add_header X-Robots-Tag "noindex" always;
    try_files $uri =404;
}

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

X-Robots-Tag служит дополнительной подсказкой, а не механизмом защиты. В примере он повторён в обработчике health.json, поскольку наличие собственных add_header влияет на наследование заголовков в распространённых конфигурациях Nginx. Перед применением смотрят версию и фактический ответ. Не нужно предполагать, что одна строка в родительском блоке обязательно появилась во всех вариантах ответа.

Что именно проверяем

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

curl --user reviewer --dump-header staging.headers \
  --output staging-old.html \
  https://staging.example.com/my/legacy/first.php

При таком вызове будущий клиент запросит пароль, не помещая его непосредственно в командную строку. В автоматической проверке способ передачи секрета проектируется отдельно и не должен раскрывать его в журнале. Команда не выполнялась при написании. Ожидаемый ответ после аутентификации — HTML старой статьи и статус 200. Без учётных данных ожидается запрос аутентификации, что проверяет уже другое свойство окружения.

Содержание Sitemap и canonical в производственном кандидате по-прежнему использует https://example.com. Это сознательный выбор: проверяем выпуск для основного адреса. Он не означает, что staging должен отправлять посетителя на production каждым запросом. Обычные ссылки внутри сайта могут быть корневыми, чтобы просмотр оставался на тестовом имени. Абсолютные ссылки, которые действительно ведут наружу, отмечают при чтении и оценивают по назначению.

Что staging не способен доказать

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

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

Решение после просмотра

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

Для наблюдения за staging отдельно определяют смысл ответа без пароля. Если внешний монитор ожидает 200 от каждой страницы, закрытое окружение будет выглядеть неисправным всё время. Корректнее либо наблюдать ожидаемый запрос аутентификации как доступность входа, либо дать монитору ограниченные учётные данные для проверки конкретного материала. Эти проверки подтверждают разные свойства. Не следует ради зелёного индикатора временно снимать пароль со всего сайта: тогда меняется сама модель окружения. Сначала описывают, какой запрос выполнен и какой ответ считается нормальным, а затем настраивают правило наблюдения.

На выходе урока есть отдельное закрытое окружение, выбранный кандидат и описанные результаты будущей проверки. Основной сайт по-прежнему может работать на прежней версии. Следующий урок применит модель к Beget, где публикация устроена иначе, чем смена ссылки на управляемом VPS.