Git-развёртывания Pages

Сначала подключите и ограничьте репозиторий по руководству Git-хостинги. Доступ к коннектору, право развёртывания Pages и право просмотра истории сборок проверяются отдельно.

Git-развёртывание Pages собирает выбранную версию репозитория и создаёт неизменяемый Deployment статического сайта. Build Worker выполняет сборку, Pages Project хранит историю версий, а Tag и Route определяют, какая версия доступна пользователям.

Главное решение — должна ли успешная сборка только создавать новую версию для проверки или сразу публиковать её через Tag. Пока у команды нет надёжной процедуры предварительного просмотра и отката, оставьте публикацию ручной. Успешная сборка доказывает лишь создание файлов сайта; она не подтверждает правильность Domain, TLS, Route и поведения сайта в браузере.

Git-сборки Pages доступны в планах Business и Enterprise. Ручная загрузка статического сайта доступна начиная с Personal. В обоих случаях Pages использует одну модель неизменяемых Deployment, поэтому проверка, публикация и откат работают одинаково.

Перед началом

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

Проверьте package.json, выберите менеджер пакетов, команду сборки и каталог результата. Итогом должны быть готовые статические файлы, например index.html, JavaScript, CSS и изображения. Pages не запускает серверное приложение: если проекту нужен постоянно работающий процесс Node.js, используйте Docker или Compose Project.

Коннектору выдавайте доступ только на чтение выбранных репозиториев. Build Worker должен иметь достаточно ресурсов для установки зависимостей и сборки, но не должен делить рабочий каталог с приложениями рабочей среды. Build Secrets доступны только внутри изолированной сборки и не должны попадать в статические файлы или публичную конфигурацию сайта.

Определите успех до включения автоматизации

До включения автоматизации зафиксируйте ветку, корневой каталог приложения, менеджер пакетов, версию Node.js, команду сборки, каталог результата, публикуемый Tag и ответственного. Определите проверку готовности: открывается ли главная страница и прямые ссылки, загружаются ли изображения и стили, корректны ли метаданные, языковые адреса, sitemap.xml и поисковый индекс, отсутствуют ли секреты в готовых файлах.

Включайте автоматические сборки, если каждое изменение выбранной ветки должно создавать новую версию. Автоматическую публикацию включайте только тогда, когда любую успешную сборку безопасно сразу назначить на выбранный Tag. Для документации и маркетинговых сайтов обычно удобнее автоматическая сборка с ручной публикацией после проверки неизменяемого предварительного адреса. Автоматические сборки источника, сохранённого после 2.11, выполняются, только пока сохранившая его учётная запись сохраняет integrations:<provider>:use на репозиторий; иначе в истории сборок появляется Build paused: <user> no longer has use on <repo>. См. «Кто может запускать и просматривать сборки?».

Соберите Deployment

1. Выберите репозиторий, ветку и нужную ревизию для Pages Project.
2. Выберите менеджер пакетов, команду сборки, каталог результата и необходимые Build Secrets.
3. Запустите сборку и следите за задачей на назначенном Build Worker.
4. Проверьте журнал сборки, исходный commit и созданный неизменяемый результат.
5. Откройте полученный Deployment по предварительному адресу и только после проверки перемещайте рабочий Tag.

Сборка намеренно отделена от публикации. Завершённая сборка создаёт неизменяемый Deployment-кандидат, но сама по себе не меняет Tag или Route. Автоматическая сборка и автоматическая публикация — независимые настройки. Вторую включайте только после того, как команда проверила процедуру выпуска и отката.

Продвиньте и проверьте

Переместите нужный Tag на одобренный Deployment. Route указывает на Tag, поэтому после этого новая версия станет доступна пользователям. Проверьте DNS и TLS публичного домена, главную страницу, статические файлы, видимую браузеру window.runtime.config и состояние операций проекта. Неизменяемый предварительный адрес позволяет проверить конкретную версию без изменения публичного Tag.

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

Неудачная сборка, отмена и откат

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

Во время обновления Opfield сборки, запущенные через webhook или опрос, откладываются и запускаются однократно после завершения обновления.

Если опубликованная версия вызвала проблему, верните Tag на предыдущий проверенный Deployment. Затем проверьте Route, статические файлы, публичную конфигурацию и состояние nginx. Не изменяйте неисправный Deployment на месте: его неизменяемая запись нужна для диагностики и подтверждения отката.

Для операторов: классификация сбоя сборки

Классифицируйте сбой до повторной попытки:

Область	Типичное свидетельство	Безопасное действие
Доступ к исходному коду	Репозиторий или commit не читается	Исправьте права коннектора; не открывайте ему всю организацию по умолчанию
Установка зависимостей	Ошибка lock-файла, реестра или менеджера пакетов	Повторите с тем же менеджером и lock-файлом; проверьте только нужный секрет реестра
Команда сборки	Скрипт завершился с ошибкой или не создал результат	Исправьте сборку в репозитории и сохраните неудачную задачу для сравнения
Каталог результата	Каталог отсутствует, пуст или не содержит статический сайт	Исправьте каталог результата; не публикуйте неполный набор файлов
Политика допуска	Сборка отклонена до публикации	Устраните нарушение политики или получите явно одобренное исключение
Публикация	Deployment существует, но Tag или Route не изменился	Проверьте настройку автоматической публикации и операцию Pages; не пересобирайте корректную версию

Отмена останавливает активную сборку, но не удаляет предыдущие Deployment и не перемещает рабочий Tag. Повторная попытка использует тот же точный commit SHA, даже если ветка уже изменилась. Запускайте новую сборку из исходного кода, если нужен новый последний commit ветки.

Ручные релизы и очистка

Ручной выпуск Pages использует ту же модель: создайте новый неизменяемый Deployment из подготовленных статических файлов, проверьте его и перемещайте Tag только после одобрения. История Git полезна для отслеживания происхождения, но ручная версия проходит тот же путь Tag и Route.

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

Для чувствительных репозиториев проверяйте журналы сборки перед передачей другим людям. Opfield маскирует управляемые Build Secrets, но скрипт сборки всё равно может вывести содержимое репозитория или производные чувствительные значения. Относитесь к описанию сборки как к коду рабочей системы и не помещайте секреты в команды, имена файлов, сгенерированные манифесты или клиентские пакеты.