Enterprise 版本

发布

概要

NextPDF Enterprise 将一次发布建模为有类型的值对象——一个发布清单、各工件清单、构建配置文件、分发渠道与访问边界——并推导出一份发布计划，将每个工件路由到正确的渠道与访问边界。

可用性与许可

此能力随 NextPDF Enterprise（nextpdf/enterprise）一同发布，并通过 Enterprise 级许可信封激活。没有该授权的部署不会加载此能力的类。对比各版本并获取许可证。

安装

composer require nextpdf/enterprise:^3

概念概览

ReleaseManifest 是某个版本的不可变顶层文档。它记录语义化版本号、源提交、构建时间戳、各工件清单的列表，以及可选的供应链佐证路径（SBOM、GPG 签名、校验和）。其 schema 版本遵循“新增项用次版本号、破坏性变更用主版本号”。

ArtifactManifest 记录一个已构建的工件：其规范文件名、版本、源提交、目标版本、交付模式、编码技术、分发渠道、目标 PHP 版本、SHA-256 摘要、可选的编码过期时间，以及构建时间戳。EncodingTechnology 区分用于编码某工件的工具与该工件是否被编码；明文工件始终为 None。

DistributionChannel 显式地分离两件事：一个工件来源（二进制存储）与一个包消费层（composer require 读取的注册表）。AccessBoundary 决定谁可以访问一个工件——付费客户、有时限的评估，或绝不面向客户的内部 CI/QA/staging——且每个边界都要求认证。

PublishingPlan 从构建配置文件与发布清单推导而来。每个配置文件解析为发布目标：一个工件来源目标和一个消费层目标，并应用正确的访问边界，使付费工件与评估工件被路由到正确的位置。

为何如此设计

关键的决定是将一次发布建模为不可变的有类型值对象，而非松散的配置。工件来源与消费层是彼此独立、由枚举定型的两件事，访问边界也是显式的。因此一个被误路由的工件——一个被放到客户渠道上的内部构建——会以建模错误的形式暴露，而不是一个静默的生产事故。该计划保持为推导而非权威：它指明预期目标，而由你的发布工具执行传输。同一批对象通过 Core 契约解析，因此升级版本的消费方无需改动任何调用代码。这种连续性正是开放内核边界的意义所在——你购买的是 Enterprise 表层，而非一次重写。设计背景：开放内核，无锁定。

API 范围

Class	Responsibility
`ReleaseManifest`	不可变的顶层发布文档。
`ArtifactManifest`	各工件的元数据与校验字段。
`BuildProfile`	待发布的一份构建配置。
`DistributionChannel`	来源渠道与消费层渠道的枚举。
`AccessBoundary`	Paid / Evaluation / Internal 访问枚举。
`EncodingTechnology`	编码工具枚举（例如已编码 / 无）。
`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 签名、校验和）。本模块记录并路由这些引用；它本身并不产出签名，也不为来源背书。请将清单视为有待你的发布流水线验证的元数据，而非其本身即为证据。

数据驻留与 PII 缓解

发布清单包含构建与工件元数据，而非个人数据。请对工件存储施加你惯常的控制措施。

安全遥测与日志清理

发布日志应记录版本与渠道，而非签名密钥材料或内部存储路径。

符合性

本模块不声明任何标准符合性；它是一个发布建模层。供应链佐证（SBOM、签名、校验和）由清单引用，并由你的发布工具产出与验证。

FIPS-mode 行为

本模块不执行任何密码学操作。GPG 签名与校验和生成由外部发布工具执行，此处仅作引用。

威胁模型

输入是调用方提供的构建配置文件与清单数据。本模型让来源与消费的区分以及访问边界的区分显式化，使误路由（例如暴露一个内部工件）成为一个可见的建模错误，而非一个静默的错误。

行为契约

ReleaseManifest 是某个版本的不可变顶层文档；其 schema 版本遵循“新增项用次版本号、破坏性变更用主版本号”。
DistributionChannel 将工件来源与包消费层保持为彼此独立的两件事；将二者混淆是一个建模错误，而本类型让这个错误显式化。
AccessBoundary 区分 Paid / Evaluation / Internal，且每个边界都要求认证；一个 Internal 工件绝不面向客户。
PublishingPlan 从构建配置文件与发布清单推导而来；它描述预期目标，对于传输并不具有权威性。

发布边界

本页仅记录外部可观察的行为与受支持的公开 API 表层。内部命名空间路径、辅助类、机制表、runbook 文件名与工单前缀均不在范围之内。

Core 回退

NextPDF Core 没有发布建模层。一个需要发布清单、构建配置文件或发布计划的仅 Core 消费方必须自行为其建模。

Pro 回退

NextPDF Pro 不提供有类型的发布清单、构建配置文件、访问边界或推导出的发布计划；它们仅在 nextpdf/enterprise 包中提供。仅有 Pro 的部署没有可满足发布建模请求的 Enterprise 组件。Enterprise 表层请参阅 Enterprise overview。

Enterprise 边界说明

清单 schema、来源与消费的区分，以及访问边界路由，仅在行为层面被描述。内部渠道解析表与内部发布目标接线不在公开范围之内，未予复述。

部署边界

发布计划是推导出来的元数据，而非传输：实际的工件上传由你的发布工具执行。供应链佐证（SBOM、GPG 签名、校验和）由清单引用，并由你的发布流水线产出与验证，而不是由本模块产出。各渠道的路由、凭据与存储由运营方负责。

法律合规边界

本页描述的是一个发布建模层。它记录并路由供应链佐证引用；它本身并不产出签名、不为来源背书、不为发布颁发证明，也不构成法律意见。将清单本身视为证据是不正确的；验证由你的发布流水线执行。判断一次发布是否满足你的合同或监管义务，是你的责任。