Jedes Salesforce-DevOps-Tool ignoriert die Paketentwicklung

Kurze Antwort: Die Kategorie Salesforce DevOps ist am Deployment von Org zu Org groß 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 veröffentlichen die meisten ISVs und PDOs ihr Produkt auch 2026 noch mit selbst geschriebenen Skripten.

Was gehört 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 völlig andere Form:

1. Abhängigkeiten zwischen eigenen Paketen und den genutzten Fremdpaketen auflösen.
2. Eine Version gegen einen Dev Hub in einer Scratch Org erzeugen, mit der richtigen Ancestry, damit der Upgrade-Pfad hält.
3. Diese Version in Test-Orgs installieren, je eine pro Edition und Konfiguration, die Sie unterstützen.
4. Die Tore passieren: Apex-Abdeckung, statische Analyse und, bei einem gelisteten Produkt, die AppExchange Security Review.
5. Die Version auf released heben, was unumkehrbar ist.
6. Sie zu Subscriber-Orgs pushen oder veröffentlichen und dann verfolgen, wer auf welcher Version sitzt.
7. Die Listing-Version aktualisieren, damit das Sichtbare dem Installierbaren entspricht.

Nur Schritt drei sieht überhaupt nach einem Deployment aus. Alles andere ist Artefaktverwaltung, und eine Pipeline, die Umgebungen modelliert, hat dafür keinen Platz.

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

Weil dort das Volumen liegt. Die große Mehrheit der Salesforce-Teams betreibt eine Produktions-Org mit einem Fächer aus Sandboxes, und ihr Release-Problem lautet ehrlich: "diese Änderung 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 enthält eine Versionsnummer. Ein Paket ist kein Diff zwischen zwei Orgs. Es ist ein unveränderliches Artefakt mit Identität, einem Vorfahren und einer Population von Installationen in Orgs, die Ihnen nicht gehören.

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 überleben.
• Ancestry. Ein falscher Vorfahre liefert kein schlechtes Release, sondern ein nicht aktualisierbares.
• Abhängigkeitsreihenfolge. 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 hängt zwei Hauptversionen zurück und blockiert eine Abkündigung.
• 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 Ökosystem es ihnen so sagt. Suchen Sie, wie man ein 2GP-Paket veröffentlicht, und Sie finden Schritt-für-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 aneinanderzuhängen. Salesforce' eigener Leitfaden zum Second-Generation Managed Packaging sagt es unumwunden: Packaging-Operationen laufen über die CLI, oder Sie automatisieren sie mit Skripten.

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

Unterdessen bewegt sich die Plattform weiter. Package Migrations wurde in Summer '25 allgemein verfügbar, 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 umhängt. 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 verstärken sich:

• Die Teams mit dem größten Bedarf können es nicht kaufen. Ein ISV mit fünf Personen hat das schwerste Release-Problem im Ökosystem und das kleinste Budget. Liegt Paketunterstützung 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 fängt Packaging-Fehler.

Wie sähe erstklassige Paketunterstützung aus?

Der Test ist einfach: Kann dieselbe Pipeline, die eine Org-Änderung ausliefert, auch eine Version schneiden, Abhängigkeiten auflösen, in eine Testmatrix installieren, promoten und Subscriber verfolgen, ohne das Produkt zu verlassen? Im selben Tarif, nicht im Enterprise-Tarif.

Genau um diese Lücke wurde Serpent gebaut, entstanden daraus, einen eHealth-ISV durch Managed Packages und die AppExchange Security Review zu führen. 1GP-, 2GP- und Managed-Package-Workflows, paketübergreifende Abhängigkeitsauflösung, Versionsverwaltung über Subscriber-Orgs und AppExchange-Release-Workflows stecken in jedem Tarif, auch im kostenlosen, mit vorgewärmtem Scratch-Org-Pooling auf Scale, damit die Validierung in einer sauberen Org günstig genug bleibt, um sie weiter laufen zu lassen. Sehen Sie, wie Serpent Paketauslieferung löst.

FAQ

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

Sie können bleiben, aber die Plattforminvestition fließt in 2GP. Package Migrations, seit Summer '25 allgemein verfügbar, konvertiert eine 1GP-Version und hängt Subscriber per Push Upgrade um.

Kann ich nicht einfach GitHub Actions nehmen?

Können Sie, und viele Teams tun es. Der Preis ist, dass Ihnen die Ancestry-Logik, die Abhängigkeitsreihenfolge, das Subscriber-Tracking und die Person gehören, die das alles versteht.

Betrifft das nur AppExchange-ISVs?

Nein. Jedes Team, das Unlocked oder Managed Packages für interne Modularität 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 zerstört den Upgrade-Pfad für jeden Subscriber, und eine promotete Version lässt sich nicht zurückstufen.