Из Git в рабочую среду

Этот сценарий ведёт от проверенной ревизии Git к неизменяемому артефакту и затем к жизненному циклу владеющего ресурса Opfield. До начала назначьте владельца репозитория, Build Worker, целевую ноду и правило отката. Если выполняете этот процесс впервые, сначала прочитайте сборки из Git и Deployments. Интеграция источника доказывает, что разрешено читать, Build Worker отвечает за изолированную сборку, реестр хранит артефакт, а Container, Deployment, Compose Project или Pages Project решает, попадёт ли он к пользователям.

Это разделение важно для управления релизами: право собирать репозиторий не даёт права менять Route рабочей среды, а успешная сборка не означает успешное развёртывание.

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

Определите владение и политику релиза

До подключения исходного кода рабочей среды согласуйте:

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

Разделяйте автоматическую сборку и автоматическую публикацию. Сборка создаёт версию-кандидат. Публикация изменяет работающий ресурс или Pages Tag и несёт другой риск.

Подготовьте границу выполнения

Настройте поддерживаемую интеграцию GitLab, GitHub, generic Git или External SSH в Settings > Integrations. Выдайте коннектору доступ только к репозиториям, необходимым для обнаружения и клонирования. Не встраивайте учётные данные в URL репозитория.

Зарегистрируйте выделенный Build Worker, убедитесь, что он имеет состояние Online и сообщает возможности execution, dedicated-runtime и resource-enforcement, необходимые для допуска сборки. Build Worker использует выделенные службы BuildKit/containerd и не открывает профилю builder обычный сокет Docker Engine.

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

Подключите ресурс

1. Создайте или откройте целевой Container, Deployment, Compose Project или Pages Project.
2. Выберите режим Repository, одобренную интеграцию, репозиторий и ветку.
3. Настройте контекст сборки и Dockerfile либо ограниченный файл Compose и поддерживаемые поля build. Для Pages выберите обнаружение менеджера пакетов, скрипт сборки, версию Node.js и каталог артефакта.
4. Добавьте Build Secrets с областью источника, только если сборка действительно в них нуждается.
5. Отдельно примите решения об автоматической сборке и автоматической публикации.
6. Сохраните конфигурацию источника и проверьте разрешённый путь репозитория до запуска кандидата рабочей среды.

Build Secrets подключаются через механизм секретов BuildKit и маскируются в поддерживаемых журналах. Это не обычные аргументы сборки: не копируйте их в ARG, ENV, файлы репозитория, метки образа, URL менеджера пакетов или трассировку командной оболочки. Вредоносный Dockerfile всё равно способен раскрыть секрет, поэтому проверка репозитория остаётся частью границы безопасности.

Соберите и одобрите артефакт

Поставьте сборку в очередь и следите за её долговременной записью. Проверьте:

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

Сборка готова к релизу только после одобрения политикой и появления артефакта в настроенном реестре или процессе Deployment Pages. Если сбой Build Worker или реестра не позволяет создать одобренный дайджест, не подменяйте его изменяемым tag образа.

Пакетное поведение Compose

Файл Compose из репозитория может создавать отдельную дочернюю сборку для каждой службы с поддерживаемой секцией build. Каждый Build Worker выполняет одну сборку за раз, поэтому при ограниченной ёмкости проект может обрабатываться последовательно.

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

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

Развёртывание и проверка

Продвигайте одобренный артефакт через жизненный цикл владельца:

• Container использует контролируемое Recreate;
• Deployment — сине-зелёный выпуск с проверкой состояния;
• Compose Project создаёт и применяет неизменяемую ревизию;
• Pages Project создаёт неизменяемый Deployment и перемещает нужный Tag.

Проверьте развёрнутый дайджест или коммит, состояние среды выполнения, журналы, публичный Route и каждую привязку базы данных. Для Pages проверьте HTML, статические ресурсы, видимую клиенту конфигурацию среды выполнения и выбранный Tag. Для рабочих нагрузок Docker убедитесь, что целевая нода загрузила одобренный дайджест, а не похожий tag.

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

Сбой и восстановление

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

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

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

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

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

Симптом	Сначала проверьте	Подробная страница
Сборка не начинается	Доступ к Git, Task и Build Worker	Сборки из Git
Новый Deployment не готов	Проверку состояния, журналы и предыдущую версию	Deployments
Публикация не отвечает	Route и ответ приложения после отката	Публикация приложения