Rilascio

In breve

NextPDF Enterprise modella una release come value object tipizzati — un manifest di release, manifest per-artefatto, profili di build, canali di distribuzione e confini di accesso — e deriva un piano di pubblicazione che instrada ogni artefatto verso il canale e il confine di accesso corretti.

Disponibilità e licenza

Questa funzionalità è inclusa in NextPDF Enterprise (nextpdf/enterprise) e si attiva con un envelope di licenza di livello Enterprise. Una distribuzione priva di tale titolo non carica le classi della funzionalità. Confronta le edizioni e ottieni una licenza.

Installazione

composer require nextpdf/enterprise:^3

Panoramica concettuale

ReleaseManifest è il documento immutabile di primo livello per una versione. Registra la versione semantica, il commit di origine, il timestamp di build, l’elenco dei manifest per-artefatto e i percorsi facoltativi delle prove di supply chain (SBOM, firma GPG, checksum). La versione del suo schema segue il principio minor-per-additivo, major-per-incompatibile.

ArtifactManifest registra un artefatto costruito: il suo nome di file canonico, la versione, il commit di origine, l’edizione di destinazione, la modalità di consegna, la tecnologia di codifica, il canale di distribuzione, la versione PHP di destinazione, il digest SHA-256, la scadenza facoltativa della codifica e il timestamp di build. EncodingTechnology distingue lo strumento usato per codificare un artefatto dal fatto che sia stato codificato del tutto; un artefatto in chiaro ha sempre None.

DistributionChannel separa esplicitamente due aspetti: un’origine dell’artefatto (archiviazione binaria) e uno strato di consumo del pacchetto (il registry che un composer require legge). AccessBoundary determina chi può accedere a un artefatto — clienti paganti, valutazione a tempo limitato o CI/QA/staging interno mai rivolto al cliente — e ogni confine richiede autenticazione.

PublishingPlan è derivato dai profili di build e dal manifest di release. Ogni profilo si risolve in destinazioni di pubblicazione: una destinazione di origine dell’artefatto e una destinazione dello strato di consumo, con applicato il corretto confine di accesso, così che gli artefatti paid ed evaluation vengano instradati nel posto giusto.

Perché funziona così

La decisione portante è modellare una release come value object tipizzati e immutabili, non come configurazione libera. L’origine dell’artefatto e lo strato di consumo sono aspetti distinti tipizzati come enum, e i confini di accesso sono espliciti. Così un artefatto instradato in modo errato — una build interna collocata su un canale cliente — emerge come errore di modellazione, non come sbaglio silenzioso in produzione. Il piano resta derivato anziché autorevole: nomina le destinazioni previste mentre il tooling di release esegue il trasporto. Gli stessi oggetti si risolvono attraverso il contratto di Core, perciò un consumatore che aggiorna edizione non cambia alcun codice chiamante. Questa continuità è il senso di un confine open-core — si acquista la superficie Enterprise, non una riscrittura. Contesto di progettazione: Open core, senza lock-in.

Superficie API

Classe	Responsabilità
ReleaseManifest	Documento di release immutabile di primo livello.
ArtifactManifest	Metadati per-artefatto e campi di verifica.
BuildProfile	Una configurazione di build da pubblicare.
DistributionChannel	Enum di canale origine vs strato di consumo.
AccessBoundary	Enum di accesso Paid / Evaluation / Internal.
EncodingTechnology	Enum dello strumento di codifica (es. encoded / none).
PublishingPlan / PublishingTarget	Piano derivato e instradamento per-destinazione.

Esempio di codice — Avvio rapido

use NextPDF\Enterprise\Release\PublishingPlan;

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

Esempio di codice — Produzione

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

Casi limite e insidie

• L’origine dell’artefatto e lo strato di consumo sono canali distinti. L’origine archivia il binario; lo strato di consumo serve i metadati che vi puntano. Non confonderli quando si ragiona sul punto in cui un composer require si risolve.
• Un artefatto in chiaro riporta sempre EncodingTechnology::None; il campo della tecnologia di codifica risponde a «quale strumento», non a «era protetto».
• Gli artefatti del confine di accesso Internal non sono mai rivolti al cliente; instradarli verso un canale cliente è un errore di configurazione che questo modello è progettato per rendere esplicito.
• Il piano di pubblicazione è derivato, non autorevole per il trasporto — descrive le destinazioni previste; il caricamento effettivo è eseguito dal tooling di release.

Prestazioni

La derivazione del piano è lineare nel numero di profili di build e produce un piccolo numero di destinazioni per profilo. I value object sono immutabili ed economici da costruire.

Note di sicurezza

Il manifest di release trasporta percorsi delle prove di supply chain (SBOM, firma GPG, checksum). Questo modulo registra e instrada tali riferimenti; non produce esso stesso firme né attesta la provenienza. Trattare il manifest come metadato da verificare con la propria pipeline di release, non come prova di per sé.

Residenza dei dati e mitigazioni dei dati personali (PII)

I manifest di release contengono metadati di build e di artefatto, non dati personali. Applicare i propri controlli abituali all’archiviazione degli artefatti.

Telemetria sicura e sanificazione dei log

I log di release dovrebbero registrare versione e canale, non materiale di chiavi di firma né percorsi di archiviazione interni.

Conformità

Non si rivendica alcuna conformità a standard per questo modulo; è uno strato di modellazione delle release. Le prove di supply chain (SBOM, firme, checksum) sono riferite dal manifest e prodotte e verificate dal tooling di release.

Comportamento in modalità FIPS

Questo modulo non esegue operazioni crittografiche. La firma GPG e la generazione dei checksum sono eseguite da tooling di release esterno e qui solo riferite.

Modello di minaccia

Gli input sono profili di build e dati di manifest forniti dal chiamante. Il modello rende esplicite le distinzioni origine-vs-consumo e di confine di accesso, così che un instradamento errato (per esempio esporre un artefatto interno) sia un errore di modellazione visibile anziché silenzioso.

Contratto di comportamento

• ReleaseManifest è il documento immutabile di primo livello per una versione; la versione del suo schema segue il principio minor-per-additivo, major-per-incompatibile.
• DistributionChannel mantiene l’origine dell’artefatto e lo strato di consumo del pacchetto come aspetti distinti; confonderli è un errore di modellazione che questo tipo rende esplicito.
• AccessBoundary distingue Paid / Evaluation / Internal, e ogni confine richiede autenticazione; un artefatto Internal non è mai rivolto al cliente.
• PublishingPlan è derivato dai profili di build e dal manifest di release; descrive le destinazioni previste e non è autorevole per il trasporto.

Confine di pubblicazione

Questa pagina documenta solo il comportamento osservabile dall’esterno e la superficie API pubblica supportata. I percorsi di namespace interni, le classi helper, le tabelle dei meccanismi, i nomi di file dei runbook e i prefissi dei ticket sono fuori ambito.

Fallback Core

NextPDF Core non ha alcuno strato di modellazione delle release. Un consumatore solo-Core che necessita di manifest di release, profili di build o un piano di pubblicazione deve modellarli da sé.

Fallback Pro

NextPDF Pro non fornisce i manifest di release tipizzati, i profili di build, i confini di accesso né il piano di pubblicazione derivato; sono inclusi esclusivamente nel pacchetto nextpdf/enterprise. Una distribuzione solo-Pro non ha alcun componente Enterprise per soddisfare una richiesta di modellazione delle release. Vedere la Panoramica Enterprise per la superficie Enterprise.

Nota sul confine Enterprise

Lo schema del manifest, la distinzione origine-vs-consumo e l’instradamento del confine di accesso sono descritti solo a livello di comportamento. Le tabelle interne di risoluzione dei canali e il cablaggio interno delle destinazioni di pubblicazione sono fuori ambito per la superficie pubblica e non sono qui riprodotti.

Confine di deployment

Il piano di pubblicazione è metadato derivato, non il trasporto: il caricamento effettivo dell’artefatto è eseguito dal tooling di release. Le prove di supply chain (SBOM, firma GPG, checksum) sono riferite dal manifest e prodotte e verificate dalla pipeline di release, non da questo modulo. L’instradamento, le credenziali e l’archiviazione per ciascun canale sono responsabilità dell’operatore.

Confine di conformità legale

Questa pagina descrive uno strato di modellazione delle release. Registra e instrada riferimenti a prove di supply chain; non produce esso stesso firme, non attesta la provenienza, non certifica una release né costituisce consulenza legale. Trattare il manifest come prova di per sé è scorretto; la verifica è eseguita dalla pipeline di release. Giudicare se una release soddisfa i propri obblighi contrattuali o normativi è responsabilità dell’utente.

Vedere anche

• Riferimento su Release
• Panoramica Enterprise
• Attivazione della licenza
• Matrice delle funzionalità Core vs Pro vs Enterprise