Jedes Salesforce-DevOps-Tool ignoriert die Paketentwicklung

Kurze Antwort: Die Kategorie Salesforce DevOps ist am Deployment von Org zu Org gross geworden, ihre Bausteine sind daher Umgebungen und Metadaten, keine versionierten Artefakte. Die Paketauslieferung, 1GP, 2GP und Managed Packages, kam als Nachgedanke dazu und wird bis heute oft als Aufpreis verkauft. Deshalb veroeffentlichen die meisten ISVs und PDOs ihr Produkt auch 2026 noch mit selbst geschriebenen Skripten.

Was gehoert wirklich zu einer Paketauslieferung?

Ein Release von Org zu Org ist kurz: Change Set bauen, gegen das Ziel validieren, deployen. Ein Paket-Release hat eine voellig andere Form:

Abhaengigkeiten zwischen eigenen Paketen und den genutzten Fremdpaketen aufloesen.
Eine Version gegen einen Dev Hub in einer Scratch Org erzeugen, mit der richtigen Ancestry, damit der Upgrade-Pfad haelt.
Diese Version in Test-Orgs installieren, je eine pro Edition und Konfiguration, die Sie unterstuetzen.
Die Tore passieren: Apex-Abdeckung, statische Analyse und, bei einem gelisteten Produkt, die AppExchange Security Review.
Die Version auf released heben, was unumkehrbar ist.
Sie zu Subscriber-Orgs pushen oder veroeffentlichen und dann verfolgen, wer auf welcher Version sitzt.
Die Listing-Version aktualisieren, damit das Sichtbare dem Installierbaren entspricht.

Nur Schritt drei sieht ueberhaupt nach einem Deployment aus. Alles andere ist Artefaktverwaltung, und eine Pipeline, die Umgebungen modelliert, hat dafuer keinen Platz.

Warum ist die Kategorie rund um Org-zu-Org gewachsen?

Weil dort das Volumen liegt. Die grosse Mehrheit der Salesforce-Teams betreibt eine Produktions-Org mit einem Faecher aus Sandboxes, und ihr Release-Problem lautet ehrlich: "diese Aenderung von UAT in die Produktion bringen, ohne etwas kaputtzumachen." Copado, Gearset, AutoRABIT, Flosum, Salto und Blue Canvas haben alle starke Produkte gegen dieses Problem gebaut, mit demselben Modell: Umgebungen, Branches, Metadaten, Diffs.

Keiner dieser Bausteine enthaelt eine Versionsnummer. Ein Paket ist kein Diff zwischen zwei Orgs. Es ist ein unveraenderliches Artefakt mit Identitaet, einem Vorfahren und einer Population von Installationen in Orgs, die Ihnen nicht gehoeren.

Was braucht eine Paket-Pipeline, das eine Org-Pipeline nicht braucht?

Ein Artefakt, keinen Diff. Die Release-Einheit ist eine Versions-Id, und sie muss den Branch, aus dem sie stammt, deutlich ueberleben.
Ancestry. Ein falscher Vorfahre liefert kein schlechtes Release, sondern ein nicht aktualisierbares.
Abhaengigkeitsreihenfolge. Ein Produkt aus mehreren Paketen installiert in einer bestimmten Reihenfolge, und die muss berechnet und nicht erinnert werden.
Scratch Orgs als Testeinheit. Paketvalidierung passiert wiederholt in einer frischen Org, wodurch Provisionierungszeit zu einem CI-Kostenfaktor wird.
Eine Subscriber-Sicht. Wer sitzt auf welcher Version, bei wem ist ein Push Upgrade gescheitert, wer haengt zwei Hauptversionen zurueck und blockiert eine Abkuendigung.
Review-Tore. Die Security Review ist bei einem gelisteten Produkt ein Release-Schritt, keine Compliance-Aufgabe, die anderswo passiert.

Warum schreiben ISVs immer noch eigene Release-Skripte?

Weil das Oekosystem es ihnen so sagt. Suchen Sie, wie man ein 2GP-Paket veroeffentlicht, und Sie finden Schritt-fuer-Schritt-Anleitungen, die eigene Pipeline in Azure DevOps oder GitHub Actions zu bauen und sf package version create und sf package version promote von Hand aneinanderzuhaengen. Salesforce' eigener Leitfaden zum Second-Generation Managed Packaging sagt es unumwunden: Packaging-Operationen laufen ueber die CLI, oder Sie automatisieren sie mit Skripten.

Fuer eine Plattform ist das eine gute Antwort. Fuer eine Kategorie, die Release-Automatisierung verkauft, ist es eine seltsame.

Unterdessen bewegt sich die Plattform weiter. Package Migrations wurde in Summer '25 allgemein verfuegbar, mit sf package convert, um eine 1GP-Version in eine 2GP-Version zu wandeln, und einem Push Upgrade mit --migrate-to-2gp, das Subscriber ohne Neuinstallation umhaengt. Ein 1GP-Anbieter hat jetzt einen echten Migrationspfad und einen echten Bedarf an einer Pipeline, die beide Generationen gleichzeitig versteht. Die meisten Werkzeuge behandeln Packaging weiterhin als angeschraubte Integration.

Was zerbricht, wenn Packaging ein Add-on ist?

Drei Dinge, und sie verstaerken sich:

Die Teams mit dem groessten Bedarf koennen es nicht kaufen. Ein ISV mit fuenf Personen hat das schwerste Release-Problem im Oekosystem und das kleinste Budget. Liegt Paketunterstuetzung hinter einer Enterprise-Stufe, schreibt dieses Team Bash, und die Skripte werden Stammeswissen mit einem Busfaktor von eins.
Der Release-Stand landet in einer Tabelle. Wenn die Pipeline keine Version halten kann, leben Ancestry und Subscriber-Versionen in einem Dokument, das freitags niemand pflegt.
Das Testen erodiert leise. Braucht eine Scratch Org Minuten und wurde die Pipeline nicht darauf ausgelegt, senkt irgendwann jemand, wie oft das Paket in einer sauberen Org validiert wird. Genau dieser Test faengt Packaging-Fehler.

Wie saehe erstklassige Paketunterstuetzung aus?

Der Test ist einfach: Kann dieselbe Pipeline, die eine Org-Aenderung ausliefert, auch eine Version schneiden, Abhaengigkeiten aufloesen, in eine Testmatrix installieren, promoten und Subscriber verfolgen, ohne das Produkt zu verlassen? Im selben Tarif, nicht im Enterprise-Tarif.

Genau um diese Luecke wurde Serpent gebaut, entstanden daraus, einen eHealth-ISV durch Managed Packages und die AppExchange Security Review zu fuehren. 1GP-, 2GP- und Managed-Package-Workflows, paketuebergreifende Abhaengigkeitsaufloesung, Versionsverwaltung ueber Subscriber-Orgs und AppExchange-Release-Workflows stecken in jedem Tarif, auch im kostenlosen, mit vorgewaermtem Scratch-Org-Pooling auf Scale, damit die Validierung in einer sauberen Org guenstig genug bleibt, um sie weiter laufen zu lassen. Sehen Sie, wie Serpent Paketauslieferung loest.

FAQ

Ist 2GP Pflicht, oder kann ich bei 1GP bleiben?

Sie koennen bleiben, aber die Plattforminvestition fliesst in 2GP. Package Migrations, seit Summer '25 allgemein verfuegbar, konvertiert eine 1GP-Version und haengt Subscriber per Push Upgrade um.

Kann ich nicht einfach GitHub Actions nehmen?

Koennen Sie, und viele Teams tun es. Der Preis ist, dass Ihnen die Ancestry-Logik, die Abhaengigkeitsreihenfolge, das Subscriber-Tracking und die Person gehoeren, die das alles versteht.

Betrifft das nur AppExchange-ISVs?

Nein. Jedes Team, das Unlocked oder Managed Packages fuer interne Modularitaet nutzt, trifft auf dieselben Bausteine, nur ohne Security Review.

Was ist der schwerste Teil eines Paket-Releases?

Ancestry und Promotion, denn beide sind unumkehrbar. Ein falscher Vorfahre zerstoert den Upgrade-Pfad fuer jeden Subscriber, und eine promotete Version laesst sich nicht zurueckstufen.