Private Composer-Auslieferung

Private Composer-Pakete, pro Kunde kontrolliert

Eine Registry allein entscheidet nicht, wer welche Version laden darf. Wir verbinden Composer, Kundenlizenzen, Zugriffstokens und nachvollziehbare Downloads – ohne den gewohnten Installationsablauf für Entwickler zu verändern.

Delivery-Setup prüfen lassen Ablauf ansehen
  • Kompatibel mit Composer 2
  • Zugriff an Kunden und Lizenzen gebunden
  • Tokens lassen sich rotieren und sperren
  • Eigenbetrieb oder Betrieb mit uns
Composer-Anfrage Zugriff freigegeben
Release Paket veröffentlicht
Registry Metadaten gefunden
Zugriff Lizenz geprüft
Auslieferung Build erhält Archiv
Composer-Konfiguration composer config repositories.softwaresilo composer https://repo.softwaresilo.io composer config --auth bearer.repo.softwaresilo.io YOUR_TOKEN
  1. 01Token gehört zu einem aktiven Kundenkonto
  2. 02Das angefragte Paket ist von der Lizenz abgedeckt
  3. 03Das freigegebene Archiv wird ausgeliefert und protokolliert
Für Entwickler bleibt der gewohnte Composer-Ablauf erhalten. Die Zugriffsentscheidung fällt auf dem Auslieferungsweg.

Kontrolle vor Skalierung

Ein Paket-Repository ist nur ein Teil der Auslieferung

Die betrieblichen Probleme beginnen, sobald der erste Kunde Zugriff erhält. Zugangsdaten, Lizenzen, Releases und Supportfälle brauchen einen durchgängigen Ablauf.

  1. 01

    Geteilte Zugangsdaten überleben das Projekt

    Ein Token, der zwischen Agenturen, Entwicklern und Build-Systemen kopiert wird, lässt sich nur schwer rotieren und kaum eindeutig zuordnen.

    KontrolleEigene Zugangsdaten pro Kunde oder Pipeline ausstellen und sperren, ohne Pakete neu zu veröffentlichen.

  2. 02

    Repository-Zugriff und Lizenz laufen auseinander

    Ein Kunde kann weiterhin Module, Add-ons oder Versionen erreichen, die der Vertrag nicht mehr abdeckt.

    KontrolleBei jeder Anfrage die aktive Kundenlizenz in die Paketfreigabe einbeziehen.

  3. 03

    Builds hängen an einem fragilen Downloadpfad

    Fehlende Archive, veraltete Metadaten oder manuelle Release-Schritte machen aus einem normalen Deployment einen Supportfall.

    KontrolleVersionierte Metadaten und unveränderliche Archive über einen überwachten, Composer-kompatiblen Pfad bereitstellen.

  4. 04

    Der Support sieht den Fehler, aber nicht die Ursache

    Ein fehlgeschlagener Installationslauf sieht gleich aus, egal ob der Token abgelaufen ist, das Paket fehlt oder die Freigabe nicht besteht.

    KontrolleDie Entscheidung protokollieren und einen eindeutigen Fehlergrund liefern, den der Support nachvollziehen kann.

Abläufe

Ein Auslieferungsweg aus vier betrieblichen Perspektiven

Release, Installation, Sperrung und Support greifen auf dieselben Paket- und Zugriffsdaten zu. Wählen Sie einen Ablauf, um die jeweilige Entscheidung zu sehen.

Quelle Versioniertes Release
Build Tests und Paket
Registry Metadaten und Archiv

Release-Pipeline

Aus einer geprüften Version wird ein unveränderliches Composer-Artefakt

Die Pipeline veröffentlicht das Paket einmal. Anschließend verweisen die Registry-Metadaten berechtigte Installationen genau auf dieses Archiv.

Eingang
Ein versioniertes und geprüftes Release aus dem Quell-Repository.
Entscheidung
Paketname, Version und Archiv müssen den Release-Regeln entsprechen.
Ergebnis
Ein unveränderliches Artefakt steht den berechtigten Kunden zur Verfügung.

Betriebsmodell

Klare Zuständigkeiten von Release bis Support

Die Auslieferung darf nicht zu einer undefinierten Blackbox werden. Ihr Team verantwortet das Software-Release, die Plattform setzt Zugriff und Auslieferung durch, und der Betrieb bleibt intern oder wird gemeinsam mit uns übernommen.

Wischen Sie horizontal, um die Zuständigkeiten zu vergleichen.

Zuständigkeiten nach BetriebsbereichIhr TeamDelivery-PlattformOptionaler Betrieb
Release-FreigabeVerantwortet Version und QualitätÜbernimmt freigegebenes Artefakt—
Paketzugriff der KundenDefiniert den vertraglichen ZugriffSetzt die Lizenzzuordnung durchPrüft Ausnahmen
Token-LebenszyklusOrdnet Benutzer oder Pipelines zuStellt aus, rotiert und sperrtÜberwacht auffällige Nutzung
Registry und ArchiveVeröffentlicht ReleasesLiefert Metadaten und ArchiveÜberwacht die Verfügbarkeit
SupportanalyseBearbeitet das PaketverhaltenLiefert Nachweise zur AnfrageOrdnet Delivery-Fehler ein

Die genaue Aufteilung wird vor der Umsetzung vereinbart. Ein Betrieb durch uns ist eine Option, keine versteckte Voraussetzung.

Den passenden Umfang wählen

Nicht jedes private Paket braucht eine Delivery-Plattform

Die richtige Lösung hängt davon ab, ob Sie ein Repository, eine betriebene Registry oder einen direkt mit Kundenlizenzen verknüpften Zugriff benötigen.

Wischen Sie horizontal, um die Ansätze zu vergleichen.

EntscheidungspunktStatisches SatisBetriebene RegistryLizenzbezogene Auslieferung
HauptaufgabeComposer-Metadaten erzeugen und hostenPrivate Paket-Registry betreibenAuslieferung an Kunden und Builds steuern
KundenzugriffIndividuelle UmsetzungKonto- und BerechtigungsmodellMit Kunden- und Lizenzdaten verknüpft
Token-LebenszyklusIndividuelle UmsetzungVerwaltete ZugangsdatenRotation und Sperrung anhand des Zugriffs
Kontext im ProtokollInfrastrukturprotokolleAktivitäten der RegistryKunde, Zugangsdaten und Paketentscheidung
BetriebIhr TeamSaaS-AnbieterIhr Team oder gemeinsam mit uns
Geeignet fürKleine, stabile interne PaketauswahlPrivate Entwicklung über mehrere TeamsKommerzielle Paketauslieferung an Kunden

Der Vergleich beschreibt die typische Rolle der Ansätze. Der konkrete Funktionsumfang hängt weiterhin von Konfiguration und Anbietertarif ab.

Architekturprüfung

Am Ende steht ein Delivery-Plan, den Sie umsetzen können

Wir verfolgen den bestehenden Weg von Release und Installation, benennen die Kontrolllücken und überführen die Ergebnisse in eine umsetzbare Reihenfolge.

  1. 01

    Den Ist-Zustand abbilden

    Repositories, Paket-Builds, Zugangsdaten, Lizenzdaten und Kunden-Onboarding.

  2. 02

    Fehlerfälle prüfen

    Abgelaufene Zugriffe, fehlende Versionen, offengelegte Tokens und nicht verfügbare Archive.

  3. 03

    Zielarchitektur festlegen

    Systemgrenzen, Anfrageweg, Zuständigkeiten, Überwachung und Wiederherstellung.

  4. 04

    Einführung planen

    Migrationsreihenfolge, Kundenkommunikation, Validierung und Rückfallpunkte.

Technische Fragen

Was Teams zu Beginn klären sollten

Die konkrete Umsetzung hängt von Ihrem Paketkatalog, Kundenmodell und den betrieblichen Zuständigkeiten ab.

Nutzen Kunden weiterhin die normalen Composer-Befehle?

Ja. Sie hinterlegen das private Repository und melden sich mit einem eigenen Token an. Paketversionen, Update-Befehle und der übrige Composer-2-Ablauf bleiben vertraut.

Kann ein Kunde denselben Token lokal und in CI verwenden?

Technisch ist das möglich. Getrennte Tokens lassen sich jedoch leichter rotieren, zuordnen und sperren. Deshalb trennen wir üblicherweise Personen, Projekte und automatisierte Pipelines.

Was passiert nach Ablauf einer Lizenz oder des Supportzeitraums?

Diese Regel wird ausdrücklich festgelegt. Der Zugriff kann sofort enden, auf bereits veröffentlichte Versionen begrenzt bleiben oder einer anderen vertraglichen Regel folgen. Die Plattform setzt die gewählte Regel durchgängig um.

Müssen bestehende Magento-Module dafür neu gebaut werden?

In der Regel nicht. Die Pakete benötigen gültige Composer-Metadaten und verlässliche, versionierte Archive. Zugriff und Auslieferung liegen um das Paket herum und nicht in dessen Magento-Code.

Kann die Plattform in unserer Infrastruktur laufen?

Ja. Das Zielmodell kann vollständig bei Ihnen, gemeinsam mit uns oder zwischen beiden Teams aufgeteilt betrieben werden. Hosting, Überwachung und Verantwortung bei Störungen werden vor der Umsetzung geklärt.