Release

Visão geral

O NextPDF Enterprise modela um release como objetos de valor tipados — um manifesto de release, manifestos por artefato, perfis de build, canais de distribuição e limites de acesso — e deriva um plano de publicação que roteia cada artefato para o canal e o limite de acesso corretos.

Disponibilidade e licenciamento

Este recurso é fornecido no NextPDF Enterprise (nextpdf/enterprise) e é ativado com um envelope de licença de nível Enterprise. Uma implantação sem essa habilitação não carrega as classes do recurso. Compare edições e obtenha uma licença.

Instalação

composer require nextpdf/enterprise:^3

Visão conceitual

ReleaseManifest é o documento imutável de nível superior para uma versão. Ele registra a versão semântica, o commit de origem, o carimbo de data/hora de build, a lista de manifestos por artefato e caminhos opcionais de evidência da cadeia de suprimentos (SBOM, assinatura GPG, checksums). Sua versão de schema segue menor-para-aditivo, maior-para-quebra.

ArtifactManifest registra um artefato construído: seu nome de arquivo canônico, versão, commit de origem, edição de destino, modo de entrega, tecnologia de codificação, canal de distribuição, versão de PHP de destino, resumo SHA-256, expiração opcional de codificação e carimbo de data/hora de build. EncodingTechnology distingue a ferramenta usada para codificar um artefato de se ele foi codificado de algum modo; um artefato em texto claro sempre tem None.

DistributionChannel separa explicitamente duas preocupações: uma origem de artefato (armazenamento de binário) e uma camada de consumo de pacote (o registro que um composer require lê). AccessBoundary determina quem pode acessar um artefato — clientes pagantes, avaliação por tempo limitado ou CI/QA/staging interno que nunca é voltado ao cliente — e todo limite exige autenticação.

PublishingPlan é derivado dos perfis de build e do manifesto de release. Cada perfil resolve para destinos de publicação: um destino de origem de artefato e um destino de camada de consumo, com o limite de acesso correto aplicado, de modo que artefatos pagos e de avaliação sejam roteados para o lugar certo.

Por que funciona assim

A decisão estrutural é modelar um release como objetos de valor tipados e imutáveis, não como configuração solta. A origem de artefato e a camada de consumo são preocupações distintas tipadas por enum, e os limites de acesso são explícitos. Assim, um artefato mal roteado — um build interno colocado em um canal de cliente — aparece como um erro de modelagem, não como um erro silencioso de produção. O plano permanece derivado em vez de autoritativo: ele nomeia os destinos pretendidos enquanto a sua ferramenta de release realiza o transporte. Os mesmos objetos são resolvidos por meio do contrato do Core, de modo que um consumidor que faz upgrade de edição não muda nenhum código chamador. Essa continuidade é o ponto de um limite open-core — você compra a superfície do Enterprise, não uma reescrita. Contexto de design: Open core, sem lock-in.

Superfície da API

Classe	Responsabilidade
ReleaseManifest	Documento de release imutável de nível superior.
ArtifactManifest	Metadados por artefato e campos de verificação.
BuildProfile	Uma configuração de build a publicar.
DistributionChannel	Enum de canal de origem vs. camada de consumo.
AccessBoundary	Enum de acesso Paid / Evaluation / Internal.
EncodingTechnology	Enum de ferramenta de codificação (por exemplo, codificado / nenhum).
PublishingPlan / PublishingTarget	Plano derivado e roteamento por destino.

Exemplo de código — Início rápido

use NextPDF\Enterprise\Release\PublishingPlan;

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

Exemplo de código — Produção

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,
    ]);
}

Casos extremos e armadilhas

• A origem de artefato e a camada de consumo são canais distintos. A origem armazena o binário; a camada de consumo serve os metadados que apontam para ele. Não os confunda ao raciocinar sobre onde um composer require resolve.
• Um artefato em texto claro sempre informa EncodingTechnology::None; o campo de tecnologia de codificação responde “qual ferramenta”, não “ele foi protegido”.
• Artefatos do limite de acesso Internal nunca são voltados ao cliente; roteá-los para um canal de cliente é um erro de configuração que este modelo foi projetado para tornar explícito.
• O plano de publicação é derivado, não autoritativo para o transporte — ele descreve destinos pretendidos; o upload efetivo é realizado pela sua ferramenta de release.

Desempenho

A derivação do plano é linear no número de perfis de build e produz um pequeno número de destinos por perfil. Os objetos de valor são imutáveis e baratos de construir.

Notas de segurança

O manifesto de release carrega caminhos de evidência da cadeia de suprimentos (SBOM, assinatura GPG, checksums). Este módulo registra e roteia essas referências; ele não produz por si só assinaturas nem atesta proveniência. Trate o manifesto como metadado a ser verificado pelo seu pipeline de release, não como prova por si só.

Residência de dados e mitigações de PII

Os manifestos de release contêm metadados de build e de artefato, não dados pessoais. Aplique os seus controles normais ao armazenamento de artefatos.

Telemetria segura e limpeza de logs

Os logs de release devem registrar versão e canal, não material de chave de assinatura nem caminhos internos de armazenamento.

Conformidade

Nenhuma conformidade com padrões é declarada para este módulo; ele é uma camada de modelagem de release. A evidência da cadeia de suprimentos (SBOM, assinaturas, checksums) é referenciada pelo manifesto e produzida e verificada pela sua ferramenta de release.

Comportamento em modo FIPS

Este módulo não realiza nenhuma operação criptográfica. A assinatura GPG e a geração de checksums são realizadas por ferramenta de release externa e apenas referenciadas aqui.

Modelo de ameaças

As entradas são perfis de build e dados de manifesto fornecidos pelo chamador. O modelo torna explícitas as distinções origem-vs-consumo e de limite de acesso, de modo que um roteamento incorreto (por exemplo, expor um artefato interno) seja um erro de modelagem visível, e não silencioso.

Contrato de comportamento

• ReleaseManifest é o documento imutável de nível superior para uma versão; sua versão de schema segue menor-para-aditivo, maior-para-quebra.
• DistributionChannel mantém a origem de artefato e a camada de consumo de pacote como preocupações distintas; confundi-las é um erro de modelagem que este tipo torna explícito.
• AccessBoundary distingue Paid / Evaluation / Internal, e todo limite exige autenticação; um artefato Internal nunca é voltado ao cliente.
• PublishingPlan é derivado dos perfis de build e do manifesto de release; ele descreve destinos pretendidos e não é autoritativo para o transporte.

Limite de publicação

Esta página documenta apenas o comportamento observável externamente e a superfície pública da API suportada. Caminhos de namespace internos, classes auxiliares, tabelas de mecanismo, nomes de arquivo de runbook e prefixos de tíquete estão fora do escopo.

Alternativa do Core

O NextPDF Core não tem nenhuma camada de modelagem de release. Um consumidor somente Core que precise de manifestos de release, perfis de build ou um plano de publicação deve modelá-los por conta própria.

Alternativa do Pro

O NextPDF Pro não fornece os manifestos de release tipados, os perfis de build, os limites de acesso nem o plano de publicação derivado; eles são fornecidos apenas no pacote nextpdf/enterprise. Uma implantação somente Pro não tem nenhum componente Enterprise para atender a uma solicitação de modelagem de release. Consulte a visão geral do Enterprise para a superfície do Enterprise.

Nota sobre o limite do Enterprise

O schema do manifesto, a distinção origem-vs-consumo e o roteamento de limite de acesso são descritos apenas no nível de comportamento. As tabelas internas de resolução de canal e a fiação interna de destino de publicação estão fora do escopo da superfície pública e não são reproduzidas aqui.

Limite de implantação

O plano de publicação é metadado derivado, não o transporte: o upload efetivo do artefato é realizado pela sua ferramenta de release. A evidência da cadeia de suprimentos (SBOM, assinatura GPG, checksums) é referenciada pelo manifesto e produzida e verificada pelo seu pipeline de release, não por este módulo. O roteamento, as credenciais e o armazenamento de cada canal são responsabilidade do operador.

Limite jurídico de conformidade

Esta página descreve uma camada de modelagem de release. Ela registra e roteia referências de evidência da cadeia de suprimentos; ela não produz por si só assinaturas, não atesta proveniência, não certifica um release nem constitui parecer jurídico. Tratar o manifesto como prova por si só é incorreto; a verificação é realizada pelo seu pipeline de release. Julgar se um release atende às suas obrigações contratuais ou regulatórias é responsabilidade sua.

Consulte também

• Referência de release
• Visão geral do Enterprise
• Ativação de licença
• Matriz de recursos Core vs Pro vs Enterprise