2GP Managed Package Valkuilen Die ISVs Echt Tijd Kosten

Kort antwoord: De duurste fouten met Salesforce second-generation (2GP) managed packages zijn de onomkeerbare. Je namespace, je global API-surface en je ancestry-strategie liggen vroeg vast, terwijl de meeste teams vijf minuten besteden aan beslissingen waar ze de hele levensduur van het product mee leven. Hieronder de valkuilen die ISVs echt weken kosten, en die ene die nooit ongedaan te maken is.

De Salesforce-documentatie noemt de meeste hiervan, maar verstopt de gevolgen. Deze gids zet ze vooraan, zodat je de permanente keuzes bewust maakt in plaats van ze bij het promoten te ontdekken.

Waarom is je package-namespace permanent?

Je namespace is niet "lastig te wijzigen." Hij is permanent. Wat je op een vrijdagmiddag in een wegwerp-Dev Hub typt, is het voorvoegsel dat je de hele levensduur van het product meedraagt. Is er enige kans dat je een package later afsplitst of verkoopt, deel dan niet een namespace over alles, want een namespace kan achteraf niet worden gesplitst. Dit is de meest onomkeerbare beslissing in de hele levenscyclus en verdient veel meer dan vijf minuten.

Hoe strandt ancestry je subscribers?

Ancestry is een boom, en je subscribers kunnen die alleen omhoog klimmen. Elke nieuwe versie declareert een ancestor, en geinstalleerde orgs upgraden langs die keten. Zet de verkeerde ancestor en je kunt klanten laten stranden op een tak die je nieuwste release niet kan bereiken.

De keerzijde is echt nuttig: als 1.3 een chaos wordt, kun je die laten vallen en 1.4 bouwen op 1.2. Maar dat werkt alleen als je de boom begreep voordat je shipte, niet erna.

Waarom installeert je "released" package niet?

Elke versie die je maakt is een beta totdat je hem promoot. Beta's kunnen niet in productie-orgs worden geinstalleerd en niet naar subscribers worden gepusht. Teams verliezen dagen met de vraag waarom hun released package niet installeert, en het antwoord is dat niemand de promote-stap heeft uitgevoerd.

Promotie voert ook validaties uit, waaronder org-types en testuitvoering, dus die kan op het laatste moment falen. Behandel promote als een echte gate, geen formaliteit.

Wanneer slaat de 75 procent code coverage-gate toe?

De eis van 75 procent coverage slaat toe bij het promoten, niet bij het maken. Je kunt de hele dag beta's maken met zwakke tests en dan tegen de muur lopen op het moment dat je voor release wilt promoten. Als je team coverage als opruimtaak voor later ziet, komt "later" precies wanneer je wilt shippen.

Welke Dev Hub-limieten stoppen je release-dag?

Dev Hub-limieten zijn reeel en resetten dagelijks. Package version creates en scratch orgs zijn per dag gemaximeerd afhankelijk van de editie. Middenin de drukte betekent het bereiken van de limiet dat je klaar bent tot morgen. Plan release-dagen rond deze limieten in plaats van ze onder druk te ontdekken.

Waarom is je Dev Hub-org een single point of failure?

Packages zijn eigendom van de Dev Hub. Verlies je toegang tot die org, door een verlopen trial, een admin die vertrok, of verloren inloggegevens, dan heb je een echt probleem. Eigendomsoverdrachten bestaan maar zijn pijnlijk. Zet de Dev Hub op een org die een verantwoordelijk persoon echt beheert, niet een trial die iemand opzette om te testen.

Wat is namespaceAccessible, en waarom vinden teams het te laat?

namespaceAccessible is het deelmechanisme dat mensen te laat ontdekken. Packages die een namespace delen, kunnen publieke Apex daardoor delen zonder global te worden. Teams die dit nooit leren, stellen ofwel global API's bloot die ze nooit kunnen terugnemen, want global is voor altijd in een managed package, ofwel dupliceren ze code over packages. Beide doen jarenlang pijn.

De kern: kies de permanente dingen bewust

2GP is een echte verbetering ten opzichte van 1GP. Het is source driven, er zijn geen packaging-orgs, en versioning is veel flexibeler. Maar bijna elke valkuil hierboven is onzichtbaar tot hij toeslaat, en meerdere zijn onomkeerbaar. De teams die soepel shippen, zijn de teams die de permanente beslissingen, namespace, global surface en ancestry-strategie, bewust aan het begin namen.

Bouw je een Salesforce DevOps-proces rond packaging, dan behandelen onze andere Salesforce DevOps-gidsen de pipeline-patronen die deze releases herhaalbaar houden.

FAQ

Kun je een managed package-namespace later wijzigen?

Nee. Een managed package-namespace is permanent en kan na koppeling niet worden gewijzigd of gesplitst. Kies hem bewust en vermijd het delen van een namespace over producten die je later kunt scheiden.

Waarom kan mijn 2GP-package niet in productie worden geinstalleerd?

Nieuw gemaakte versies zijn beta's. Beta's installeren alleen in scratch- en sandbox-orgs. Promoot de versie naar released voordat hij in productie kan installeren of naar subscribers kan worden gepusht.

Wanneer wordt de 75 procent testcoverage voor 2GP afgedwongen?

Bij promotie, niet bij het maken van een versie. Je kunt beta's bouwen met lage coverage, maar je kunt een versie pas voor release promoten als hij de 75 procent-gate haalt.

Is een global Apex-methode omkeerbaar in een managed package?

Nee. Eenmaal geshipt is een global member deel van je permanente API-surface. Gebruik liever namespaceAccessible om code te delen tussen packages in dezelfde namespace dan iets global bloot te stellen dat je nooit kunt verwijderen.