Publication

En bref

NextPDF Enterprise modélise une version sous forme d’objets-valeurs typés — un manifeste de version, des manifestes par artefact, des profils de build, des canaux de distribution, et des frontières d’accès — et dérive un plan de publication qui route chaque artefact vers le bon canal et la bonne frontière d’accès.

Disponibilité & licence

Cette capacité est livrée dans NextPDF Enterprise (nextpdf/enterprise) et s’active avec une enveloppe de licence de palier Enterprise. Un déploiement dépourvu de cette autorisation ne charge pas les classes de la capacité. Comparer les éditions et obtenir une licence.

Installation

composer require nextpdf/enterprise:^3

Vue d’ensemble conceptuelle

ReleaseManifest est le document immuable de plus haut niveau pour une version. Il enregistre la version sémantique, le commit source, l’horodatage de build, la liste des manifestes par artefact, et des chemins facultatifs de preuves de chaîne d’approvisionnement (SBOM, signature GPG, sommes de contrôle). Sa version de schéma suit la règle mineure pour un ajout, majeure pour une rupture.

ArtifactManifest enregistre un artefact construit : son nom de fichier canonique, sa version, son commit source, son édition cible, son mode de livraison, sa technologie d’encodage, son canal de distribution, sa version PHP cible, son empreinte SHA-256, son expiration d’encodage facultative, et son horodatage de build. EncodingTechnology distingue l’outil utilisé pour encoder un artefact du fait qu’il ait été encodé ou non ; un artefact en clair a toujours None.

DistributionChannel sépare explicitement deux préoccupations : une origine d’artefact (stockage binaire) et une couche de consommation de paquet (le registre que lit un composer require). AccessBoundary détermine qui peut accéder à un artefact — clients payants, évaluation à durée limitée, ou CI/QA/préproduction interne jamais exposée au client — et chaque frontière exige une authentification.

PublishingPlan est dérivé des profils de build et du manifeste de version. Chaque profil se résout en cibles de publication : une cible d’origine d’artefact et une cible de couche de consommation, avec la frontière d’accès correcte appliquée afin que les artefacts payants et d’évaluation soient routés au bon endroit.

Pourquoi cela fonctionne ainsi

La décision porteuse consiste à modéliser une version comme des objets-valeurs typés immuables, et non comme une configuration lâche. L’origine d’artefact et la couche de consommation sont des préoccupations distinctes typées par enum, et les frontières d’accès sont explicites. Ainsi, un artefact mal routé — un build interne placé sur un canal client — se manifeste comme une erreur de modélisation, et non comme une erreur de production silencieuse. Le plan reste dérivé plutôt que faisant autorité : il nomme les cibles visées pendant que ton outillage de version effectue le transport. Les mêmes objets se résolvent via le contrat du Core, de sorte qu’un consommateur qui change d’édition ne modifie aucun code appelant. Cette continuité est tout l’intérêt d’une frontière open-core — tu achètes la surface Enterprise, pas une réécriture. Contexte de conception : Open core, sans verrouillage.

Surface d’API

Classe	Responsabilité
ReleaseManifest	Document de version immuable de plus haut niveau.
ArtifactManifest	Métadonnées et champs de vérification par artefact.
BuildProfile	Une configuration de build à publier.
DistributionChannel	Enum de canal origine vs couche de consommation.
AccessBoundary	Enum d’accès Paid / Evaluation / Internal.
EncodingTechnology	Enum d’outil d’encodage (par ex. encodé / aucun).
PublishingPlan / PublishingTarget	Plan dérivé et routage par cible.

Exemple de code — Démarrage rapide

use NextPDF\Enterprise\Release\PublishingPlan;

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

Exemple de code — Production

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

Cas limites & pièges

• L’origine d’artefact et la couche de consommation sont des canaux distincts. L’origine stocke le binaire ; la couche de consommation sert les métadonnées qui pointent vers lui. Ne les confonds pas lorsque tu raisonnes sur l’endroit où un composer require se résout.
• Un artefact en clair rapporte toujours EncodingTechnology::None ; le champ de technologie d’encodage répond à « quel outil », pas à « était-il protégé ».
• Les artefacts de la frontière d’accès Internal ne sont jamais exposés au client ; les router vers un canal client est une erreur de configuration que ce modèle est conçu pour rendre explicite.
• Le plan de publication est dérivé, et non faisant autorité pour le transport — il décrit les cibles visées ; le téléversement effectif est réalisé par ton outillage de version.

Performance

La dérivation du plan est linéaire en nombre de profils de build et produit un petit nombre de cibles par profil. Les objets-valeurs sont immuables et peu coûteux à construire.

Notes de sécurité

Le manifeste de version porte des chemins de preuves de chaîne d’approvisionnement (SBOM, signature GPG, sommes de contrôle). Ce module enregistre et route ces références ; il ne produit pas lui-même de signatures et n’atteste pas la provenance. Traite le manifeste comme une métadonnée à vérifier par ton pipeline de version, et non comme une preuve à lui seul.

Résidence des données & mesures d’atténuation des PII

Les manifestes de version contiennent des métadonnées de build et d’artefact, et non des données personnelles. Applique tes contrôles habituels au stockage des artefacts.

Télémétrie sûre & nettoyage des journaux

Les journaux de version devraient enregistrer la version et le canal, et non le matériel de clé de signature ni les chemins de stockage internes.

Conformité

Aucune conformité à des normes n’est revendiquée pour ce module ; c’est une couche de modélisation de version. Les preuves de chaîne d’approvisionnement (SBOM, signatures, sommes de contrôle) sont référencées par le manifeste et produites et vérifiées par ton outillage de version.

Comportement en mode FIPS

Ce module n’effectue aucune opération cryptographique. La signature GPG et la génération de sommes de contrôle sont réalisées par un outillage de version externe et seulement référencées ici.

Modèle de menace

Les entrées sont des profils de build et des données de manifeste fournis par l’appelant. Le modèle rend explicites les distinctions origine-vs-consommation et de frontière d’accès, de sorte qu’un mauvais routage (par exemple exposer un artefact interne) est une erreur de modélisation visible plutôt que silencieuse.

Contrat de comportement

• ReleaseManifest est le document immuable de plus haut niveau pour une version ; sa version de schéma suit la règle mineure pour un ajout, majeure pour une rupture.
• DistributionChannel maintient l’origine d’artefact et la couche de consommation de paquet comme des préoccupations distinctes ; les confondre est une erreur de modélisation que ce type rend explicite.
• AccessBoundary distingue Paid / Evaluation / Internal, et chaque frontière exige une authentification ; un artefact Internal n’est jamais exposé au client.
• PublishingPlan est dérivé des profils de build et du manifeste de version ; il décrit les cibles visées et n’est pas faisant autorité pour le transport.

Frontière de publication

Cette page documente uniquement le comportement observable de l’extérieur et la surface d’API publique prise en charge. Les chemins d’espace de noms internes, les classes utilitaires, les tables de mécanisme, les noms de fichiers de runbook et les préfixes de ticket sont hors périmètre.

Repli sur le Core

NextPDF Core n’a aucune couche de modélisation de version. Un consommateur Core uniquement qui a besoin de manifestes de version, de profils de build ou d’un plan de publication doit les modéliser lui-même.

Repli sur Pro

NextPDF Pro ne fournit pas les manifestes de version typés, les profils de build, les frontières d’accès ni le plan de publication dérivé ; ils sont livrés uniquement dans le paquet nextpdf/enterprise. Un déploiement Pro uniquement n’a aucun composant Enterprise pour satisfaire une demande de modélisation de version. Voir la présentation de Enterprise pour la surface Enterprise.

Note sur la frontière Enterprise

Le schéma du manifeste, la distinction origine-vs-consommation et le routage par frontière d’accès sont décrits au niveau du comportement uniquement. Les tables internes de résolution de canal et le câblage interne des cibles de publication sont hors du périmètre de la surface publique et ne sont pas reproduits ici.

Frontière de déploiement

Le plan de publication est une métadonnée dérivée, et non le transport : le téléversement effectif de l’artefact est réalisé par ton outillage de version. Les preuves de chaîne d’approvisionnement (SBOM, signature GPG, sommes de contrôle) sont référencées par le manifeste et produites et vérifiées par ton pipeline de version, et non par ce module. Le routage, les identifiants et le stockage de chaque canal relèvent de la responsabilité de l’opérateur.

Frontière de conformité légale

Cette page décrit une couche de modélisation de version. Elle enregistre et route des références de preuves de chaîne d’approvisionnement ; elle ne produit pas elle-même de signatures, n’atteste pas la provenance, ne certifie pas une version et ne constitue pas un avis juridique. Traiter le manifeste comme une preuve à lui seul est incorrect ; la vérification est réalisée par ton pipeline de version. Juger si une version satisfait tes obligations contractuelles ou réglementaires relève de ta responsabilité.

Voir aussi

• Référence de publication
• Présentation de Enterprise
• Activation de licence
• Matrice des fonctionnalités Core vs Pro vs Enterprise