Выпуск

Кратко

NextPDF Enterprise моделирует выпуск как типизированные объекты-значения — манифест выпуска, манифесты для каждого артефакта, профили сборки, каналы распространения и границы доступа — и выводит план публикации, который маршрутизирует каждый артефакт в правильный канал и границу доступа.

Доступность и лицензирование

Эта возможность поставляется в NextPDF Enterprise (nextpdf/enterprise) и активируется лицензионным конвертом уровня Enterprise. Развёртывание без этого права не загружает классы данной возможности. Сравните редакции и получите лицензию.

Установка

composer require nextpdf/enterprise:^3

Концептуальный обзор

ReleaseManifest — это неизменяемый документ верхнего уровня для версии. Он фиксирует семантическую версию, исходный коммит, временную метку сборки, список манифестов для каждого артефакта и необязательные пути к доказательствам цепочки поставок (SBOM, подпись GPG, контрольные суммы). Его версия схемы следует правилу minor для добавлений, major для несовместимых изменений.

ArtifactManifest описывает один собранный артефакт: его каноническое имя файла, версию, исходный коммит, целевую редакцию, режим доставки, технологию кодирования, канал распространения, целевую версию PHP, дайджест SHA-256, необязательный срок действия кодирования и временную метку сборки. EncodingTechnology отличает инструмент, использованный для кодирования артефакта, от того, было ли оно применено вообще; артефакт в открытом тексте всегда имеет None.

DistributionChannel явно разделяет два аспекта: источник артефакта (двоичное хранилище) и слой потребления пакета (реестр, который читает composer require). AccessBoundary определяет, кто может получить доступ к артефакту — платные клиенты, ознакомление с ограничением по времени или внутренние CI/QA/staging, которые никогда не предназначены для клиента — и каждая граница требует аутентификации.

PublishingPlan выводится из профилей сборки и манифеста выпуска. Каждый профиль разрешается в цели публикации: цель источника артефакта и цель слоя потребления, с применением правильной границы доступа, чтобы платные и ознакомительные артефакты маршрутизировались в нужное место.

Почему это работает именно так

Ключевое решение — моделировать выпуск как неизменяемые типизированные объекты-значения, а не как свободную конфигурацию. Источник артефакта и слой потребления — это различные аспекты, типизированные перечислениями, а границы доступа заданы явно. Поэтому неправильно маршрутизированный артефакт — внутренняя сборка, помещённая в клиентский канал — проявляется как ошибка моделирования, а не как молчаливая ошибка в продакшене. План остаётся производным, а не авторитетным: он называет предполагаемые цели, тогда как перенос выполняет ваш инструментарий выпуска. Те же объекты разрешаются через контракт Core, поэтому потребитель, обновляющий редакцию, не меняет вызывающий код. Именно в этой непрерывности смысл границы open core — вы покупаете поверхность Enterprise, а не переписывание. Предыстория дизайна: Открытое ядро, без привязки к поставщику.

Поверхность API

Класс	Ответственность
ReleaseManifest	Неизменяемый документ выпуска верхнего уровня.
ArtifactManifest	Метаданные и поля проверки для каждого артефакта.
BuildProfile	Конфигурация сборки для публикации.
DistributionChannel	Перечисление канала: источник или слой потребления.
AccessBoundary	Перечисление доступа Paid / Evaluation / Internal.
EncodingTechnology	Перечисление инструмента кодирования (например, encoded / none).
PublishingPlan / PublishingTarget	Производный план и маршрутизация по целям.

Пример кода — быстрый старт

use NextPDF\Enterprise\Release\PublishingPlan;

$plan = PublishingPlan::fromProfiles($profiles, '3.1.0');

Пример кода — продакшен

use NextPDF\Enterprise\Release\PublishingPlan;
use NextPDF\Enterprise\Release\PublishingEnvironment;

$plan = PublishingPlan::fromProfiles(
    $profiles,
    '3.1.0',
    PublishingEnvironment::Production,
);

foreach ($plan->targets as $target) {
    $logger->info('release.target', [
        'version' => $plan->version,
        'channel' => $target->channel->value,
    ]);
}

Граничные случаи и подводные камни

• Источник артефакта и слой потребления — это разные каналы. Источник хранит двоичный файл; слой потребления отдаёт метаданные, указывающие на него. Не смешивайте их, рассуждая о том, где разрешается composer require.
• Артефакт в открытом тексте всегда сообщает EncodingTechnology::None; поле технологии кодирования отвечает на вопрос «какой инструмент», а не «был ли он защищён».
• Артефакты с границей доступа Internal никогда не предназначены для клиента; их маршрутизация в клиентский канал — ошибка конфигурации, которую эта модель призвана делать явной.
• План публикации является производным, а не авторитетным для транспорта — он описывает предполагаемые цели; фактическую загрузку выполняет ваш инструментарий выпуска.

Производительность

Вывод плана линеен по числу профилей сборки и создаёт небольшое число целей на профиль. Объекты-значения неизменяемы и дёшевы в конструировании.

Замечания по безопасности

Манифест выпуска несёт пути к доказательствам цепочки поставок (SBOM, подпись GPG, контрольные суммы). Этот модуль фиксирует и маршрутизирует эти ссылки; он сам не создаёт подписей и не подтверждает происхождение. Относитесь к манифесту как к метаданным, которые проверяет ваш конвейер выпуска, а не как к доказательству самому по себе.

Размещение данных и меры по защите ПДн

Манифесты выпуска содержат метаданные сборки и артефактов, а не персональные данные. Применяйте обычные меры контроля к хранению артефактов.

Безопасная телеметрия и очистка журналов

Журналы выпуска должны записывать версию и канал, а не материал ключа подписания или внутренние пути хранения.

Соответствие

Соответствие стандартам для этого модуля не заявляется; это слой моделирования выпусков. Доказательства цепочки поставок (SBOM, подписи, контрольные суммы) указываются манифестом, а создаются и проверяются вашим инструментарием выпуска.

Поведение в режиме FIPS

Этот модуль не выполняет криптографических операций. Подписание GPG и генерация контрольных сумм выполняются внешним инструментарием выпуска и здесь только упоминаются.

Модель угроз

Входные данные — это предоставленные вызывающим кодом профили сборки и данные манифеста. Модель делает явными различия «источник против потребления» и границы доступа, поэтому неправильная маршрутизация (например, раскрытие внутреннего артефакта) — это видимая ошибка моделирования, а не молчаливая.

Контракт поведения

• ReleaseManifest — это неизменяемый документ верхнего уровня для версии; его версия схемы следует правилу minor для добавлений, major для несовместимых изменений.
• DistributionChannel сохраняет источник артефакта и слой потребления пакета как отдельные аспекты; их смешивание — ошибка моделирования, которую этот тип делает явной.
• AccessBoundary различает Paid / Evaluation / Internal, и каждая граница требует аутентификации; артефакт Internal никогда не предназначен для клиента.
• PublishingPlan выводится из профилей сборки и манифеста выпуска; он описывает предполагаемые цели и не является авторитетным для транспорта.

Граница публикации

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

Резервный вариант Core

У NextPDF Core нет слоя моделирования выпусков. Потребитель только с Core, которому нужны манифесты выпуска, профили сборки или план публикации, должен моделировать их сам.

Резервный вариант Pro

NextPDF Pro не предоставляет типизированных манифестов выпуска, профилей сборки, границ доступа или производного плана публикации; они поставляются только в пакете nextpdf/enterprise. При развёртывании только с Pro нет компонента Enterprise для удовлетворения запроса на моделирование выпуска. См. обзор Enterprise для поверхности Enterprise.

Примечание о границе Enterprise

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

Граница развёртывания

План публикации — это производные метаданные, а не транспорт: фактическую загрузку артефакта выполняет ваш инструментарий выпуска. Доказательства цепочки поставок (SBOM, подпись GPG, контрольные суммы) указываются манифестом, а создаются и проверяются вашим конвейером выпуска, а не этим модулем. Маршрутизация, учётные данные и хранение для каждого канала — ответственность оператора.

Граница юридического соответствия

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

См. также

• Справочник по выпуску
• Обзор Enterprise
• Активация лицензии
• Матрица возможностей Core, Pro и Enterprise