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 fruh festgelegt, obwohl die meisten Teams funf 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 ruckgangig gemacht werden kann.

Die Salesforce-Dokumentation erwahnt 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 andern." Er ist permanent. Was du an einem Freitagnachmittag in einen Wegwerf-Dev-Hub tippst, ist das Prafix, das du die gesamte Lebensdauer des Produkts tragst. Besteht auch nur die Chance, dass du ein Package spater abspaltest oder verkaufst, teile nicht einen Namespace uber alles, denn ein Namespace kann danach nicht geteilt werden. Das ist die unumkehrbarste Entscheidung im gesamten Lebenszyklus und verdient weit mehr als funf Minuten.

Wie strandet Ancestry deine Subscriber?

Ancestry ist ein Baum, und deine Subscriber konnen 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 nutzlich: 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 "veroffentlichtes" Package nicht?

Jede Version, die du erstellst, ist eine Beta, bis du sie promotest. Betas konnen nicht in Produktions-Orgs installiert und nicht an Subscriber gepusht werden. Teams verlieren Tage mit der Frage, warum sich ihr veroffentlichtes Package nicht installiert, und die Antwort ist, dass niemand den Promote-Schritt ausgefuhrt hat.

Die Promotion fuhrt auch Validierungen aus, einschliesslich Org-Typen und Testausfuhrung, sie kann also auf den letzten Metern fehlschlagen. Behandle Promote als echtes Gate, nicht als Formalitat.

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 fur die Release promoten willst. Wenn dein Team Coverage als Aufraumaufgabe fur spater behandelt, kommt "spater" genau dann, wenn du ausliefern willst.

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

Dev-Hub-Limits sind real und setzen sich taglich zuruck. 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 gehoren 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. Eigentumsubertragungen existieren, sind aber muhsam. 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 spat?

namespaceAccessible ist der Sharing-Mechanismus, den Leute zu spat entdecken. Packages, die einen Namespace teilen, konnen offentlichen Apex daruber teilen, ohne global zu werden. Teams, die das nie lernen, legen entweder global APIs offen, die sie nie zurucknehmen konnen, denn global ist in einem Managed Package fur immer, oder sie duplizieren Code uber Packages. Beides schmerzt jahrelang.

Der Kernpunkt: Entscheide die permanenten Dinge bewusst

2GP ist eine echte Verbesserung gegenuber 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 zubeisst, 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-Leitfaden die Pipeline-Muster, die diese Releases wiederholbar halten.

FAQ

Kann man einen Managed-Package-Namespace spater andern?

Nein. Ein Managed-Package-Namespace ist permanent und kann nach der Verknupfung nicht geandert oder geteilt werden. Wahle ihn bewusst und vermeide es, einen Namespace uber Produkte zu teilen, die du spater trennen konntest.

Warum lasst 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 veroffentlichten Zustand, bevor sie sich in Produktion installieren oder an Subscriber gepusht werden kann.

Wann wird die 75-Prozent-Testabdeckung fur 2GP erzwungen?

Bei der Promotion, nicht bei der Versionserstellung. Du kannst Betas mit geringer Abdeckung bauen, aber du kannst eine Version erst fur 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.