2GP Managed Package Fallstricke, Die ISVs Echte Zeit Kosten

Kurze Antwort: Die teuersten Fehler bei Salesforce Second-Generation (2GP) Managed Packages sind die unumkehrbaren. Dein Namespace, deine global API-Surface und deine Ancestry-Strategie werden früh festgelegt, obwohl die meisten Teams fünf Minuten auf Entscheidungen verwenden, mit denen sie die gesamte Lebensdauer des Produkts leben. Nachfolgend die Fallstricke, die ISVs wirklich Wochen kosten, und der eine, der nie rückgängig gemacht werden kann.

Die Salesforce-Dokumentation erwähnt die meisten davon, verschweigt aber die Konsequenzen. Dieser Leitfaden stellt sie nach vorne, damit du die permanenten Entscheidungen bewusst triffst, statt sie beim Promoten zu entdecken.

Warum ist dein Package-Namespace permanent?

Dein Namespace ist nicht "schwer zu ändern." Er ist permanent. Was du an einem Freitagnachmittag in einen Wegwerf-Dev-Hub tippst, ist das Präfix, das du die gesamte Lebensdauer des Produkts trägst. Besteht auch nur die Chance, dass du ein Package später abspaltest oder verkaufst, teile nicht einen Namespace über alles, denn ein Namespace kann danach nicht geteilt werden. Das ist die unumkehrbarste Entscheidung im gesamten Lebenszyklus und verdient weit mehr als fünf Minuten.

Wie strandet Ancestry deine Subscriber?

Ancestry ist ein Baum, und deine Subscriber können ihn nur erklimmen. Jede neue Version deklariert einen Ancestor, und installierte Orgs aktualisieren entlang dieser Kette. Setze den falschen Ancestor und du kannst Kunden auf einem Ast stranden lassen, der deine neueste Version nicht erreichen kann.

Die Kehrseite ist wirklich nützlich: Wenn 1.3 ein Chaos wird, kannst du sie aufgeben und 1.4 auf Basis von 1.2 bauen. Aber das funktioniert nur, wenn du den Baum verstanden hast, bevor du ausgeliefert hast, nicht danach.

Warum installiert sich dein "veröffentlichtes" Package nicht?

Jede Version, die du erstellst, ist eine Beta, bis du sie promotest. Betas können nicht in Produktions-Orgs installiert und nicht an Subscriber gepusht werden. Teams verlieren Tage mit der Frage, warum sich ihr veröffentlichtes Package nicht installiert, und die Antwort ist, dass niemand den Promote-Schritt ausgeführt hat.

Die Promotion führt auch Validierungen aus, einschließlich Org-Typen und Testausführung, sie kann also auf den letzten Metern fehlschlagen. Behandle Promote als echtes Gate, nicht als Formalität.

Wann greift das 75-Prozent-Code-Coverage-Gate?

Die Anforderung von 75 Prozent Coverage greift beim Promoten, nicht beim Erstellen. Du kannst den ganzen Tag Betas mit schwachen Tests erzeugen und dann gegen die Wand laufen, sobald du für die Release promoten willst. Wenn dein Team Coverage als Aufräumaufgabe für später behandelt, kommt "später" genau dann, wenn du ausliefern willst.

Welche Dev-Hub-Limits stoppen deinen Release-Tag?

Dev-Hub-Limits sind real und setzen sich täglich zurück. Package-Version-Creates und Scratch Orgs sind je nach Edition pro Tag gedeckelt. Mitten im Ansturm bedeutet das Erreichen des Limits, dass du bis morgen fertig bist. Plane Release-Tage um diese Limits herum, statt sie unter Druck zu entdecken.

Warum ist deine Dev-Hub-Org ein Single Point of Failure?

Packages gehören dem Dev Hub. Verlierst du den Zugang zu dieser Org, durch ein abgelaufenes Trial, einen ausgeschiedenen Admin oder verlorene Zugangsdaten, hast du ein echtes Problem. Eigentumsübertragungen existieren, sind aber mühsam. Lege den Dev Hub auf eine Org, die eine verantwortliche Person wirklich kontrolliert, nicht ein Trial, das jemand zum Testen aufgesetzt hat.

Was ist namespaceAccessible, und warum finden Teams es zu spät?

namespaceAccessible ist der Sharing-Mechanismus, den Leute zu spät entdecken. Packages, die einen Namespace teilen, können öffentlichen Apex darüber teilen, ohne global zu werden. Teams, die das nie lernen, legen entweder global APIs offen, die sie nie zurücknehmen können, denn global ist in einem Managed Package für immer, oder sie duplizieren Code über Packages. Beides schmerzt jahrelang.

Der Kernpunkt: Entscheide die permanenten Dinge bewusst

2GP ist eine echte Verbesserung gegenüber 1GP. Es ist source driven, es gibt keine Packaging-Orgs, und das Versioning ist weit flexibler. Aber fast jeder Fallstrick oben ist unsichtbar, bis er zubeißt, und mehrere sind unumkehrbar. Die Teams, die reibungslos ausliefern, sind die, die die permanenten Entscheidungen, Namespace, Global-Surface und Ancestry-Strategie, bewusst am Anfang getroffen haben.

Wenn du einen Salesforce-DevOps-Prozess rund um Packaging aufbaust, behandeln unsere weiteren Salesforce-DevOps-Leitfäden die Pipeline-Muster, die diese Releases wiederholbar halten.

FAQ

Kann man einen Managed-Package-Namespace später ändern?

Nein. Ein Managed-Package-Namespace ist permanent und kann nach der Verknüpfung nicht geändert oder geteilt werden. Wähle ihn bewusst und vermeide es, einen Namespace über Produkte zu teilen, die du später trennen könntest.

Warum lässt sich mein 2GP-Package nicht in Produktion installieren?

Neu erstellte Versionen sind Betas. Betas installieren sich nur in Scratch- und Sandbox-Orgs. Promote die Version in den veröffentlichten Zustand, bevor sie sich in Produktion installieren oder an Subscriber gepusht werden kann.

Wann wird die 75-Prozent-Testabdeckung für 2GP erzwungen?

Bei der Promotion, nicht bei der Versionserstellung. Du kannst Betas mit geringer Abdeckung bauen, aber du kannst eine Version erst für die Release promoten, wenn sie das 75-Prozent-Gate erreicht.

Ist eine global Apex-Methode in einem Managed Package umkehrbar?

Nein. Einmal ausgeliefert, ist ein global Member Teil deiner permanenten API-Surface. Bevorzuge namespaceAccessible, um Code zwischen Packages desselben Namespace zu teilen, statt etwas Globales offenzulegen, das du nie entfernen kannst.