Octibiz
Demo

Durchsucht Website und Dokumentation gemeinsam. Enter zeigt alle Treffer, Esc schließt.

Verteilen und versionieren

Es gibt drei Wege, ein Plugin in eine Instanz zu bringen. Welchen du nimmst, hängt davon ab, wer das Plugin pflegt.

WegFür wenWie
EingechecktPlugins, die zum System gehörenEintrag in der Bundle-Liste, Namensraum in der Paketdatei
Paket-ManagerPlugins mit eigenem Repositorycomposer require
Paket-DateiAuslieferung an Kunden ohne EntwicklungszugangZIP hochladen oder per Befehl einspielen

Weg A: eingecheckt

Der Weg für alles, was mit dem System zusammen gepflegt wird. Zwei Einträge, beschrieben im Schnellstart.

Weg B: über den Paket-Manager

composer require acme/octibiz-shipping

Das Paket trägt den Typ octibiz-plugin. Ein Installations-Helfer erkennt es und schreibt die Bundle-Liste neu. Danach installierst du es wie jedes andere.

Dieser Weg prüft die Vertragsversion nicht. Du bist selbst dafür verantwortlich, dass dein Plugin zur Hauptlinie der Instanz passt.

Weg C: als Paket-Datei

zip -r ../AcmeShipping.zip .

Die Manifest-Datei muss in der Wurzel des Archivs liegen, nicht in einem Unterordner.

Einspielen entweder über die Oberfläche oder per Befehl:

bin/console octibiz:plugin:install-package AcmeShipping.zip

Der Ablauf ist festgelegt und rollt bei jedem Fehler zurück: entpacken, Container neu bauen, Migrationen fahren, einrichten, und wenn es eine Oberfläche gibt, diese neu bauen.

Vorher laufen Prüfungen, alle vor dem ersten Seiteneffekt: die Vertragsversion, ob ein Adress-Segment des Kerns beansprucht wird, ob der Klassenname schon belegt ist.

Das Archiv wird streng gelesen: Größenbudget, Zahl der Einträge, Kompressionsverhältnis, und Pfade, die aus dem Zielverzeichnis herausführen, werden abgewiesen. Verknüpfungen im Archiv werden neutralisiert.

Es gibt keine Signaturprüfung. Wer ein Paket einspielt, führt fremden Code aus. Das ist eine bewusste Entscheidung für den derzeitigen Einsatz und kein Versehen; behandle Pakete entsprechend.

Drei Versionsachsen

Sie werden regelmäßig verwechselt:

AchseWas sie beschreibt
SystemversionDer Stand der Plattform
Plugin-VersionDer Stand deines Plugins
VertragsversionDie Stabilität der Schnittstellen zwischen beiden

Eine Änderung an deinem Plugin hebt die Systemversion nicht. Ein Bruch im Vertrag hebt keine von beiden.

Wäre es eine Zahl, sagte sie nichts: Sie änderte sich, weil in irgendeinem Modul ein Tippfehler behoben wurde, und niemand könnte ihr ansehen, ob ein Update lohnt.

Deine Version steht an vier Stellen

Maßgeblich ist die Konstante im Descriptor. Dieselbe Nummer steht in beiden Paketdateien und im obersten Abschnitt des Änderungsprotokolls.

make bump TARGET=acme.shipping BUMP=minor

Der Befehl zieht alle vier mit. Ohne Einträge unter „Unveröffentlicht" bricht er ab, statt eine Version ohne Inhalt zu erzeugen.

Die Vertragsversion

Sie steht in deiner Manifest-Datei und sagt, gegen welche Fläche du gebaut hast.

Die Zusage lautet: Innerhalb einer Hauptlinie bleibt die stabile Fläche rückwärtskompatibel. Ein Bruch erzwingt eine neue Hauptversion. Was als stabil gilt, ist eingefroren und wird bei jedem Bau gegen einen Abgleich geprüft.

Die Vertragsversion ist keine Achse, die du selbst pflegst. Du nennst sie nur.

Der Marktplatz

Es gibt ihn noch nicht. Die Schnittstelle dafür ist entworfen und im Code vorhanden, aber jeder Aufruf endet mit dem Hinweis, dass er nicht eingerichtet ist. Es gibt keine Endpunkte, keinen Katalog, keine Prüfung eingereichter Plugins.

Wer heute ausliefert, nimmt einen der drei Wege oben.

Eigenständig entwickeln

Ohne Zugang zum System-Quelltext gibt es die Vertragsfläche als zwei Pakete, je eines für Backend und Oberfläche. Beide folgen der Vertragsachse.

{
  "require-dev": { "octibiz/plugin-sdk": "~3.15.0" },
  "devDependencies": { "@octibiz/plugin-sdk": "~3.15.0" }
}

Nur als Entwicklungs-Abhängigkeit. Zur Laufzeit liefert die Instanz die echten Klassen; läge das Paket dort mit, gäbe es jede Klasse zweimal.

Was im Paket ist: die Basisklasse, alle Verträge, die eingefrorenen Ereignisklassen, die Übergabeformen, der Manifest-Vertrag der Oberfläche.

Was nicht: Klassen, die in keiner eingefrorenen Signatur vorkommen. Entities, API-Ressourcen, Repositories und die Dienste dahinter gehören dem System, nicht dem Vertrag. Für Integrationstests gegen die laufende Plattform brauchst du einen Entwicklungs-Checkout.

Vor der Auslieferung

  • Der Generator-Rest ist raus, besonders die Beispiel-Ressource
  • Alle vier Versionsstellen stimmen überein
  • Das Änderungsprotokoll nennt, was sich geändert hat
  • Die Vertragsversion im Manifest passt zur Zielinstanz
  • make gate ist grün

Weiter

  • Lebenszyklus — was beim Einspielen und Entfernen passiert
  • Testen — die Liste vor dem Ausliefern

plugin.distribution · Gilt ab Version 0.5.0