Elke Salesforce DevOps-tool negeert package development

Kort antwoord: de Salesforce DevOps-categorie is groot geworden met org-naar-org deployment, dus haar bouwstenen zijn omgevingen en metadata, geen geversioneerde artefacten. Package-levering, 1GP, 2GP en managed packages, kwam er als bijzaak bij en wordt nog steeds vaak als upgrade verkocht. Daarom brengen de meeste ISV's en PDO's hun product in 2026 nog altijd uit met scripts die ze zelf hebben geschreven.

Wat komt er eigenlijk kijken bij package-levering?

Een org-naar-org release is kort: bouw een change set, valideer tegen de doelomgeving, deploy. Een package-release heeft een heel andere vorm:

1. Los afhankelijkheden op tussen je eigen packages en die waarop je voortbouwt.
2. Maak een versie aan tegen een Dev Hub, in een scratch org, met de juiste ancestry zodat het upgradepad blijft kloppen.
3. Installeer die versie in testorgs, een per editie en configuratie die je ondersteunt.
4. Haal de poorten: Apex-dekking, statische analyse, en voor een gepubliceerd product de AppExchange security review.
5. Promoveer de versie naar released, wat onomkeerbaar is.
6. Push of publiceer naar subscriber-orgs en houd bij wie op welke versie zit.
7. Werk de listing-versie bij zodat wat klanten zien overeenkomt met wat ze kunnen installeren.

Alleen stap drie lijkt op een deployment. De rest is artefactbeheer, en een pipeline die omgevingen modelleert heeft daar geen plek voor.

Waarom is de categorie rond org-naar-org gegroeid?

Omdat daar het volume zit. De overgrote meerderheid van Salesforce-teams draait een productie-org met een waaier sandboxen, en hun releaseprobleem is oprecht: "krijg deze wijziging van UAT naar productie zonder iets te slopen." Copado, Gearset, AutoRABIT, Flosum, Salto en Blue Canvas hebben allemaal sterke producten gebouwd tegen dat probleem, met hetzelfde model: omgevingen, branches, metadata, diffs.

Geen van die bouwstenen bevat een versienummer. Een package is geen diff tussen twee orgs. Het is een onveranderlijk artefact met een identiteit, een voorouder en een populatie installaties in orgs die jij niet beheert.

Wat heeft een package-pipeline nodig dat een org-pipeline niet heeft?

• Een artefact, geen diff. De releaseeenheid is een versie-id, en die moet veel langer meegaan dan de branch waar hij uit kwam.
• Ancestry. Zit de voorouder fout, dan heb je geen slechte release uitgebracht maar een die niet te upgraden is.
• Volgorde van afhankelijkheden. Producten met meerdere packages installeren in een specifieke volgorde, en die volgorde moet berekend worden, niet onthouden.
• Scratch orgs als testeenheid. Packagevalidatie gebeurt telkens in een verse org, waardoor provisioningtijd een CI-kostenpost wordt in plaats van een detail.
• Zicht op subscribers. Wie zit op welke versie, bij wie faalde een push upgrade, wie loopt twee majors achter en blokkeert een deprecatie.
• Reviewpoorten. Security review is een releasestap voor een gepubliceerd product, geen compliancekarwei dat elders gebeurt.

Waarom schrijven ISV's nog steeds hun eigen releasescripts?

Omdat het ecosysteem hun dat vertelt. Zoek op hoe je een 2GP-package uitbrengt en je vindt stapsgewijze gidsen om zelf een pipeline te bouwen in Azure DevOps of GitHub Actions, met sf package version create en sf package version promote handmatig aan elkaar geknoopt. Salesforce' eigen gids voor second-generation managed packaging zegt het onomwonden: packaging-operaties draai je via de CLI, of je automatiseert ze met scripts.

Dat is een prima antwoord voor een platform. Het is een vreemd antwoord voor een categorie die releaseautomatisering verkoopt.

Ondertussen beweegt het platform door. Package Migrations werd algemeen beschikbaar in Summer '25, met sf package convert om een 1GP-versie in een 2GP-versie om te zetten en een --migrate-to-2gp push upgrade die subscribers omzet zonder herinstallatie. Een 1GP-uitgever heeft nu een echt migratiepad, en een echte behoefte aan een pipeline die beide generaties tegelijk snapt. De meeste tooling behandelt packaging nog als een integratie die je erbij schroeft.

Wat gaat er stuk als packaging een add-on is?

Drie dingen, en ze versterken elkaar:

• De teams die het het hardst nodig hebben kunnen het niet kopen. Een ISV van vijf mensen heeft het lastigste releaseprobleem in het ecosysteem en het kleinste budget. Zit packagesupport achter een enterprise-tier, dan schrijft dat team bash, en die scripts worden stamkennis met een buskans van een.
• Releasestatus belandt in een spreadsheet. Als de pipeline geen versie kan vasthouden, leven ancestry en subscriberversies in een document dat op vrijdag niemand bijwerkt.
• Testen verwatert stilletjes. Duurt een scratch org minuten om te provisionen en is de pipeline daar niet op gebouwd, dan verlaagt iemand uiteindelijk hoe vaak het package in een schone org wordt gevalideerd. Precies de test die packagefouten vangt.

Hoe ziet volwaardige packageondersteuning eruit?

De toets is simpel: kan dezelfde pipeline die een org-wijziging uitrolt ook een versie snijden, afhankelijkheden oplossen, in een testmatrix installeren, promoveren en subscribers volgen, zonder het product te verlaten? Op hetzelfde plan, niet op het enterprise-plan.

Dat is het gat waar Serpent omheen is gebouwd, ontstaan uit het draaien van een eHealth-ISV door managed packages en de AppExchange security review. 1GP-, 2GP- en managed-packageworkflows, cross-package dependency resolution, versiebeheer over subscriber-orgs en AppExchange-releaseworkflows zitten in elk plan, ook het gratis plan, met voorverwarmde scratch org pooling op Scale zodat validatie in een schone org betaalbaar blijft. Bekijk hoe Serpent package-levering aanpakt.

FAQ

Is 2GP verplicht, of kan ik op 1GP blijven?

Je kunt blijven, maar de platforminvestering gaat naar 2GP. Package Migrations, algemeen beschikbaar sinds Summer '25, converteert een 1GP-versie en zet subscribers om met een push upgrade.

Kan ik niet gewoon GitHub Actions gebruiken?

Dat kan, en veel teams doen het. De prijs is dat jij eigenaar wordt van de ancestrylogica, de afhankelijkheidsvolgorde, de subscribertracking en de persoon die het allemaal snapt.

Geldt dit alleen voor AppExchange-ISV's?

Nee. Elk team dat unlocked of managed packages gebruikt voor interne modulariteit raakt dezelfde bouwstenen, minus de security review.

Wat is het lastigste deel van een packagerelease?

Ancestry en promotie, want beide zijn onomkeerbaar. Een verkeerde voorouder breekt het upgradepad voor elke subscriber, en een gepromoveerde versie kun je niet terugdraaien.