Przejdź do głównej zawartości
getnextpdf.com

Enterprise edycja

Wydanie

NextPDF Enterprise modeluje wydanie jako typowane obiekty wartości — manifest wydania, manifesty dla poszczególnych artefaktów, profile kompilacji, kanały dystrybucji oraz granice dostępu — i wyprowadza plan publikacji, który kieruje każdy artefakt do właściwego kanału i właściwej granicy dostępu.

Ta funkcja jest dostarczana w NextPDF Enterprise (nextpdf/enterprise) i aktywuje się wraz z kopertą licencyjną w warstwie Enterprise. Wdrożenie bez tego uprawnienia nie ładuje klas tej funkcji. Porównaj edycje i uzyskaj licencję.

Okno terminala
composer require nextpdf/enterprise:^3

ReleaseManifest to niezmienny dokument najwyższego poziomu dla danej wersji. Rejestruje wersję semantyczną, commit źródłowy, znacznik czasu kompilacji, listę manifestów dla poszczególnych artefaktów oraz opcjonalne ścieżki dowodów łańcucha dostaw (SBOM, podpis GPG, sumy kontrolne). Jego wersja schematu zmienia się minor dla dodatków i major dla zmian łamiących.

ArtifactManifest rejestruje jeden zbudowany artefakt: jego kanoniczną nazwę pliku, wersję, commit źródłowy, docelową edycję, tryb dostarczania, technologię kodowania, kanał dystrybucji, docelową wersję PHP, skrót SHA-256, opcjonalny termin wygaśnięcia kodowania oraz znacznik czasu kompilacji. EncodingTechnology odróżnia narzędzie użyte do zakodowania artefaktu od tego, czy w ogóle został on zakodowany; artefakt jawnotekstowy zawsze ma None.

DistributionChannel jawnie rozdziela dwie kwestie: źródło artefaktu (magazyn binariów) oraz warstwę konsumpcji pakietu (rejestr, który odczytuje composer require). AccessBoundary określa, kto może uzyskać dostęp do artefaktu — płatni klienci, ograniczona w czasie ewaluacja lub wewnętrzne CI/QA/staging, które nigdy nie jest udostępniane klientowi — a każda granica wymaga uwierzytelnienia.

PublishingPlan jest wyprowadzany z profili kompilacji oraz manifestu wydania. Każdy profil rozwiązuje się do celów publikacji: celu źródła artefaktu oraz celu warstwy konsumpcji, z zastosowaną właściwą granicą dostępu, dzięki czemu artefakty płatne i ewaluacyjne są kierowane we właściwe miejsce.

Nośną decyzją jest zamodelowanie wydania jako niezmiennych typowanych obiektów wartości, a nie luźnej konfiguracji. Źródło artefaktu i warstwa konsumpcji to odrębne, wyliczeniowo typowane kwestie, a granice dostępu są jawne. Dzięki temu błędnie skierowany artefakt — wewnętrzna kompilacja umieszczona w kanale klienta — ujawnia się jako błąd modelowania, a nie cicha pomyłka produkcyjna. Plan pozostaje wyprowadzony, a nie autorytatywny: nazywa zamierzone cele, podczas gdy twoje narzędzia wydania wykonują transport. Te same obiekty rozwiązują się przez kontrakt Core, więc konsument, który aktualizuje edycję, nie zmienia żadnego kodu wywołującego. Ta ciągłość jest sensem granicy open-core — kupujesz powierzchnię Enterprise, a nie przepisanie od nowa. Tło projektowe: Otwarty rdzeń, bez uzależnienia od dostawcy.

KlasaOdpowiedzialność
ReleaseManifestNiezmienny dokument wydania najwyższego poziomu.
ArtifactManifestMetadane artefaktu oraz pola weryfikacyjne.
BuildProfileKonfiguracja kompilacji do opublikowania.
DistributionChannelWyliczenie kanału: źródło a warstwa konsumpcji.
AccessBoundaryWyliczenie dostępu Paid / Evaluation / Internal.
EncodingTechnologyWyliczenie narzędzia kodowania (np. zakodowany / brak).
PublishingPlan / PublishingTargetWyprowadzony plan oraz kierowanie dla poszczególnych celów.
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,
]);
}
  • Źródło artefaktu oraz warstwa konsumpcji to odrębne kanały. Źródło przechowuje binarium; warstwa konsumpcji udostępnia metadane, które na nie wskazują. Nie utożsamiaj ich, rozważając, gdzie rozwiązuje się composer require.
  • Artefakt jawnotekstowy zawsze zgłasza EncodingTechnology::None; pole technologii kodowania odpowiada na pytanie „które narzędzie”, a nie „czy był chroniony”.
  • Artefakty z granicy dostępu Internal nigdy nie są udostępniane klientowi; ich skierowanie do kanału klienta to błąd konfiguracji, który ten model ma czynić jawnym.
  • Plan publikacji jest wyprowadzony, a nie autorytatywny dla transportu — opisuje zamierzone cele; faktyczne przesłanie wykonuje twoje narzędzia wydania.

Wyprowadzenie planu jest liniowe względem liczby profili kompilacji i tworzy niewielką liczbę celów na profil. Obiekty wartości są niezmienne i tanie w konstrukcji.

Manifest wydania niesie ścieżki dowodów łańcucha dostaw (SBOM, podpis GPG, sumy kontrolne). Ten moduł rejestruje i kieruje te odniesienia; sam nie wytwarza podpisów ani nie poświadcza pochodzenia. Traktuj manifest jako metadane do zweryfikowania przez twój potok wydania, a nie jako dowód sam w sobie.

Manifesty wydania zawierają metadane kompilacji i artefaktów, a nie dane osobowe. Zastosuj swoje zwykłe mechanizmy kontroli do magazynu artefaktów.

Logi wydania powinny rejestrować wersję i kanał, a nie materiał klucza podpisującego ani wewnętrzne ścieżki magazynu.

Nie deklaruje się żadnej zgodności ze standardami dla tego modułu; to warstwa modelowania wydań. Dowody łańcucha dostaw (SBOM, podpisy, sumy kontrolne) są przywoływane przez manifest oraz wytwarzane i weryfikowane przez twoje narzędzia wydania.

Ten moduł nie wykonuje żadnych operacji kryptograficznych. Podpisywanie GPG oraz generowanie sum kontrolnych są wykonywane przez zewnętrzne narzędzia wydania i tutaj jedynie przywoływane.

Wejściem są dostarczone przez wywołującego profile kompilacji oraz dane manifestu. Model czyni jawnymi rozróżnienia źródło–konsumpcja oraz granica dostępu, dzięki czemu błędne skierowanie (na przykład ujawnienie artefaktu wewnętrznego) jest widocznym błędem modelowania, a nie cichym.

  • ReleaseManifest to niezmienny dokument najwyższego poziomu dla danej wersji; jego wersja schematu zmienia się minor dla dodatków i major dla zmian łamiących.
  • DistributionChannel utrzymuje źródło artefaktu oraz warstwę konsumpcji pakietu jako odrębne kwestie; ich utożsamienie to błąd modelowania, który ten typ czyni jawnym.
  • AccessBoundary rozróżnia Paid / Evaluation / Internal, a każda granica wymaga uwierzytelnienia; artefakt Internal nigdy nie jest udostępniany klientowi.
  • PublishingPlan jest wyprowadzany z profili kompilacji oraz manifestu wydania; opisuje zamierzone cele i nie jest autorytatywny dla transportu.

Ta strona dokumentuje wyłącznie zewnętrznie obserwowalne zachowanie oraz wspieraną publiczną powierzchnię API. Wewnętrzne ścieżki przestrzeni nazw, klasy pomocnicze, tabele mechanizmów, nazwy plików runbooków oraz prefiksy zgłoszeń są poza zakresem.

NextPDF Core nie ma warstwy modelowania wydań. Konsument wyłącznie z Core, który potrzebuje manifestów wydania, profili kompilacji lub planu publikacji, musi je sam zamodelować.

NextPDF Pro nie zapewnia typowanych manifestów wydania, profili kompilacji, granic dostępu ani wyprowadzonego planu publikacji; są one dostarczane wyłącznie w pakiecie nextpdf/enterprise. Wdrożenie wyłącznie z Pro nie ma komponentu Enterprise spełniającego żądanie modelowania wydania. Zobacz Przegląd Enterprise, aby poznać powierzchnię Enterprise.

Schemat manifestu, rozróżnienie źródło–konsumpcja oraz kierowanie według granicy dostępu są opisane wyłącznie na poziomie zachowania. Wewnętrzne tabele rozwiązywania kanałów oraz wewnętrzne mechanizmy wiązania celów publikacji są poza zakresem powierzchni publicznej i nie są tutaj odtwarzane.

Plan publikacji to wyprowadzone metadane, a nie transport: faktyczne przesłanie artefaktu wykonuje twoje narzędzia wydania. Dowody łańcucha dostaw (SBOM, podpis GPG, sumy kontrolne) są przywoływane przez manifest oraz wytwarzane i weryfikowane przez twój potok wydania, a nie przez ten moduł. Kierowanie, poświadczenia oraz przechowywanie dla każdego kanału należą do obowiązków operatora.

Ta strona opisuje warstwę modelowania wydań. Rejestruje i kieruje odniesienia do dowodów łańcucha dostaw; sama nie wytwarza podpisów, nie poświadcza pochodzenia, nie certyfikuje wydania ani nie stanowi porady prawnej. Traktowanie manifestu jako dowodu samego w sobie jest błędne; weryfikację wykonuje twój potok wydania. Ocena, czy wydanie spełnia twoje obowiązki umowne lub regulacyjne, należy do ciebie.