Enterprise Edition

Release

Auf einen Blick

NextPDF Enterprise modelliert ein Release als typisierte Value Objects — ein Release-Manifest, Manifeste pro Artefakt, Build-Profile, Distributionskanäle und Zugriffsgrenzen — und leitet einen Publishing-Plan ab, der jedes Artefakt zum korrekten Channel und zur korrekten Zugriffsgrenze routet.

Verfügbarkeit & Lizenzierung

Diese Fähigkeit wird in NextPDF Enterprise (nextpdf/enterprise) ausgeliefert und aktiviert sich mit einer Lizenzhülle der Enterprise-Stufe. Ein Deployment ohne diese Berechtigung lädt die Klassen der Fähigkeit nicht. Editionen vergleichen und Lizenz erwerben.

Installation

composer require nextpdf/enterprise:^3

Konzeptioneller Überblick

ReleaseManifest ist das unveränderliche Top-Level-Dokument für eine Version. Es erfasst die semantische Version, den Quell-Commit, den Build-Zeitstempel, die Liste der Manifeste pro Artefakt und optionale Supply-Chain-Evidenzpfade (SBOM, GPG-Signatur, Prüfsummen). Seine Schema-Version folgt minor-for-additive, major-for-breaking.

ArtifactManifest erfasst ein gebautes Artefakt: seinen kanonischen Dateinamen, die Version, den Quell-Commit, die Ziel-Edition, den Auslieferungsmodus, die Encoding-Technologie, den Distributionskanal, die Ziel-PHP-Version, den SHA-256-Digest, einen optionalen Encoding-Ablauf und den Build-Zeitstempel. EncodingTechnology unterscheidet das zum Encoden eines Artefakts verwendete Werkzeug von der Frage, ob es überhaupt encodet wurde; ein Klartext-Artefakt hat stets None.

DistributionChannel trennt zwei Belange explizit: einen Artefaktursprung (Binärspeicher) und eine Paket-Konsumschicht (die Registry, die ein composer require liest). AccessBoundary bestimmt, wer auf ein Artefakt zugreifen darf — zahlende Kunden, zeitlich begrenzte Evaluierung oder internes CI/QA/Staging, das niemals kundenseitig ist — und jede Grenze erfordert Authentifizierung.

PublishingPlan wird aus den Build-Profilen und dem Release-Manifest abgeleitet. Jedes Profil löst zu Publishing-Zielen auf: einem Artefaktursprung-Ziel und einem Konsumschicht-Ziel, mit der korrekt angewandten Zugriffsgrenze, sodass bezahlte und Evaluierungs-Artefakte an die richtige Stelle geroutet werden.

Warum es so funktioniert

Die tragende Entscheidung ist, ein Release als unveränderliche typisierte Value Objects zu modellieren, nicht als lose Konfiguration. Artefaktursprung und Konsumschicht sind eigenständige, Enum-typisierte Belange, und Zugriffsgrenzen sind explizit. So tritt ein fehlgeleitetes Artefakt — ein interner Build auf einem Kunden-Channel — als Modellierungsfehler zutage und nicht als stiller Produktionsfehler. Der Plan bleibt abgeleitet statt maßgeblich: Er benennt beabsichtigte Ziele, während Ihr Release-Tooling den Transport ausführt. Dieselben Objekte werden über den Core-Vertrag aufgelöst, sodass ein Konsument, der die Edition hochstuft, keinen aufrufenden Code ändert. Diese Kontinuität ist der Sinn einer Open-Core-Grenze — Sie kaufen die Enterprise-Oberfläche, keine Neuimplementierung. Design-Hintergrund: Open Core, kein Lock-in.

API-Oberfläche

Klasse	Verantwortung
`ReleaseManifest`	Unveränderliches Top-Level-Release-Dokument.
`ArtifactManifest`	Metadaten und Verifikationsfelder pro Artefakt.
`BuildProfile`	Eine zu veröffentlichende Build-Konfiguration.
`DistributionChannel`	Channel-Enum: Ursprung vs. Konsumschicht.
`AccessBoundary`	Paid- / Evaluation- / Internal-Zugriffs-Enum.
`EncodingTechnology`	Encoding-Werkzeug-Enum (z. B. encoded / none).
`PublishingPlan` / `PublishingTarget`	Abgeleiteter Plan und Routing pro Ziel.

Codebeispiel — Schnellstart

use NextPDF\Enterprise\Release\PublishingPlan;

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

Codebeispiel — Produktion

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

Sonderfälle & Fallstricke

Der Artefaktursprung und die Konsumschicht sind getrennte Channels. Der Ursprung speichert das Binary; die Konsumschicht liefert die Metadaten aus, die darauf verweisen. Vermengen Sie sie nicht, wenn Sie überlegen, wo ein composer require auflöst.
Ein Klartext-Artefakt meldet stets EncodingTechnology::None; das Encoding-Technologie-Feld beantwortet „welches Werkzeug“, nicht „war es geschützt“.
Artefakte mit Internal-Zugriffsgrenze sind niemals kundenseitig; sie in einen Kunden-Channel zu routen, ist ein Konfigurationsfehler, den dieses Modell explizit machen soll.
Der Publishing-Plan ist abgeleitet, nicht maßgeblich für den Transport — er beschreibt beabsichtigte Ziele; der eigentliche Upload wird von Ihrem Release-Tooling ausgeführt.

Performance

Die Plan-Ableitung ist linear in der Anzahl der Build-Profile und erzeugt eine kleine Anzahl von Zielen pro Profil. Die Value Objects sind unveränderlich und günstig zu konstruieren.

Sicherheitshinweise

Das Release-Manifest trägt Supply-Chain-Evidenzpfade (SBOM, GPG-Signatur, Prüfsummen). Dieses Modul erfasst und routet diese Verweise; es erzeugt selbst keine Signaturen und attestiert keine Provenienz. Behandeln Sie das Manifest als von Ihrer Release-Pipeline zu verifizierende Metadaten, nicht als Nachweis für sich allein.

Datenresidenz & PII-Minderungen

Release-Manifeste enthalten Build- und Artefakt-Metadaten, keine personenbezogenen Daten. Wenden Sie Ihre normalen Kontrollen auf den Artefaktspeicher an.

Sichere Telemetrie & Log-Bereinigung

Release-Logs sollten Version und Channel erfassen, nicht Signierschlüsselmaterial oder interne Speicherpfade.

Konformität

Für dieses Modul wird keine Standardkonformität beansprucht; es ist eine Release-Modellierungsschicht. Supply-Chain-Evidenz (SBOM, Signaturen, Prüfsummen) wird vom Manifest referenziert und von Ihrem Release-Tooling erzeugt und verifiziert.

FIPS-Modus-Verhalten

Dieses Modul führt keine kryptografischen Operationen aus. GPG-Signierung und Prüfsummen-Erzeugung werden von externem Release-Tooling ausgeführt und hier nur referenziert.

Bedrohungsmodell

Eingaben sind vom Aufrufer bereitgestellte Build-Profile und Manifestdaten. Das Modell macht die Unterscheidungen Ursprung-vs-Konsum und Zugriffsgrenze explizit, sodass eine Fehlleitung (zum Beispiel die Offenlegung eines internen Artefakts) ein sichtbarer Modellierungsfehler ist und kein stiller.

Verhaltensvertrag

ReleaseManifest ist das unveränderliche Top-Level-Dokument für eine Version; seine Schema-Version folgt minor-for-additive, major-for-breaking.
DistributionChannel hält Artefaktursprung und Paket-Konsumschicht als getrennte Belange; sie zu vermengen, ist ein Modellierungsfehler, den dieser Typ explizit macht.
AccessBoundary unterscheidet Paid / Evaluation / Internal, und jede Grenze erfordert Authentifizierung; ein Internal-Artefakt ist niemals kundenseitig.
PublishingPlan wird aus Build-Profilen und dem Release-Manifest abgeleitet; er beschreibt beabsichtigte Ziele und ist nicht maßgeblich für den Transport.

Veröffentlichungsgrenze

Diese Seite dokumentiert ausschließlich extern beobachtbares Verhalten und die unterstützte öffentliche API-Oberfläche. Interne Namespace-Pfade, Hilfsklassen, Mechanismus-Tabellen, Runbook-Dateinamen und Ticket-Präfixe liegen außerhalb des Umfangs.

Core-Fallback

NextPDF Core hat keine Release-Modellierungsschicht. Ein Core-only-Konsument, der Release-Manifeste, Build-Profile oder einen Publishing-Plan benötigt, muss sie selbst modellieren.

Pro-Fallback

NextPDF Pro stellt die typisierten Release-Manifeste, Build-Profile, Zugriffsgrenzen oder den abgeleiteten Publishing-Plan nicht bereit; sie werden ausschließlich im Paket nextpdf/enterprise ausgeliefert. Ein Pro-only-Deployment hat keine Enterprise-Komponente, um eine Release-Modellierungsanforderung zu erfüllen. Siehe den Enterprise-Überblick für die Enterprise-Oberfläche.

Hinweis zur Enterprise-Grenze

Das Manifest-Schema, die Unterscheidung Ursprung-vs-Konsum und das Routing der Zugriffsgrenzen werden ausschließlich auf Verhaltensebene beschrieben. Die internen Channel-Auflösungstabellen und die interne Verdrahtung der Publishing-Ziele liegen außerhalb des Umfangs der öffentlichen Oberfläche und werden hier nicht wiedergegeben.

Deployment-Grenze

Der Publishing-Plan ist abgeleitete Metadaten, nicht der Transport: Der eigentliche Artefakt-Upload wird von Ihrem Release-Tooling ausgeführt. Supply-Chain-Evidenz (SBOM, GPG-Signatur, Prüfsummen) wird vom Manifest referenziert und von Ihrer Release-Pipeline erzeugt und verifiziert, nicht von diesem Modul. Routing, Anmeldedaten und Speicher für jeden Channel liegen in der Verantwortung des Betreibers.

Grenze der rechtlichen Compliance

Diese Seite beschreibt eine Release-Modellierungsschicht. Sie erfasst und routet Verweise auf Supply-Chain-Evidenz; sie erzeugt selbst keine Signaturen, attestiert keine Provenienz, zertifiziert kein Release und stellt keine Rechtsberatung dar. Das Manifest als Nachweis für sich allein zu behandeln, ist falsch; die Verifikation erfolgt durch Ihre Release-Pipeline. Zu beurteilen, ob ein Release Ihre vertraglichen oder regulatorischen Pflichten erfüllt, liegt in Ihrer Verantwortung.