Andrew Hanna
Andrew Hanna
Toen Salesforce voor het eerst packaging introduceerde, werd het niet gezien als ontwikkelstrategie. Het was een manier om componenten te bundelen voor distributie, vooral voor ISV's die apps voor AppExchange bouwden.
De meeste interne teams vertrouwden nog op change sets, handmatige deployments en metadata migration tools. Het idee van modulaire, geversioneerde ontwikkeling lag ver weg.
Na verloop van tijd veranderde het Salesforce-ecosysteem ingrijpend. Wat begon als een optionele feature voor een kleine groep ISV's, is uitgegroeid tot een centrale pijler in hoe moderne Salesforce engineeringteams systemen bouwen, deployen en onderhouden.
Die reis begrijpen verklaart waarom packaging niet langer alleen “nice to have” is; het is de basis van schaalbare ontwikkeling.
Voordat Salesforce DX bestond, gebeurde development direct in orgs. Teams bouwden features in sandboxes, gebruikten change sets of ANT scripts om metadata te deployen en hadden vaak geen enkele source of truth. First-generation managed packages (1GP) hielpen ISV's applicaties distribueren en intellectueel eigendom beschermen, maar kwamen met grote beperkingen.
Package creation en versioning waren gekoppeld aan de packaging org zelf. Code leefde in de org en developers moesten afhankelijkheden handmatig beheren. Er was geen echte koppeling met Git of CI/CD, waardoor samenwerking traag en foutgevoelig was.
Voor de meeste interne Salesforce-teams voelde packaging overdreven. Ze bleven bij directe deployments omdat dat sneller was, tenminste totdat systemen groot genoeg werden dat het niet meer zo was.
Het kantelpunt kwam met Salesforce DX (SFDX) en de Salesforce CLI. Het introduceerde een developer-first aanpak: source-driven development, scratch orgs en externe version control. Voor het eerst was de org niet langer de source of truth.
Deze verschuiving definieerde opnieuw hoe packages werden gemaakt en onderhouden. Metadata kon worden geëxtraheerd, in Git opgeslagen en consistent via geautomatiseerde pipelines gedeployed. Salesforce introduceerde unlocked packages voor klanten en partners, ontworpen om grote monolithische orgs op te delen in kleinere, modulaire componenten die onafhankelijk konden evolueren.
Die hielpen teams geleidelijk overstappen van traditionele org development zonder alles tegelijk te hoeven refactoren.
Als je je hele Salesforce-carrière direct in orgs hebt gebouwd, begint de verschuiving hier logisch te worden. Je hoeft niet alles in één nacht te verplaatsen. Je kunt klein beginnen, één feature, module of businessproces verpakken, en dat in source control volgen.
Heb je ooit een wijziging willen terugdraaien zonder uren werk te verliezen? Of precies willen zien wat tussen releases veranderde? Of met vertrouwen deployen omdat elke afhankelijkheid is meegenomen? Dat maken org-dependent unlocked packages mogelijk.
Ze laten je versioning, modulaire ontwikkeling en CI/CD-practices adopteren zonder je bestaande structuur te breken. Geen grote refactor. Geen volledige metadata migration. Alleen een praktisch pad van org-gebaseerd bouwen naar moderne, source-driven development.
Deze stappen markeerden een duidelijke richting: Salesforce wilde elk team, niet alleen ISV's, richting modulaire, source-controlled delivery bewegen in een tempo dat bij hun werkelijkheid past.
De introductie van second-generation managed packages (2GP) bevestigde deze evolutie. In plaats van alles in één packaging org te bouwen en beheren, konden developers nu packages direct vanuit hun lokale source maken, via Git versionen en via de CLI releasen.
Dit was een grote verandering. Packaging werd compatibel met CI/CD-tools, geautomatiseerd testen en moderne ontwikkelpraktijken. 2GP verbeterde ook dependency handling, namespace management en security, terwijl het beter aansloot op hoe de meeste SaaS-platforms releases beheren.
Vandaag is second-generation packaging de standaardroute voor nieuwe ISV's en steeds vaker voor enterprise teams die onderhoudbare, schaalbare development workflows willen. Salesforce blijft investeren in betere tooling, van het DevHub model en scratch orgs tot de DevOps Center interface die veel CLI-werk voor admins abstraheert.
Jarenlang werd packaging als optioneel gezien, iets dat je pas adopteerde zodra je org een bepaalde grootte of complexiteit bereikte. Die kijk raakt snel verouderd. De realiteit is dat elk Salesforce-team, intern of commercieel, profiteert van source control en geversioneerde packages.
De voordelen gaan verder dan deploymentsnelheid. Source-driven development zorgt voor reproduceerbaarheid, eenvoudiger auditing en veiligere releases. Het elimineert het “werkt in sandbox maar breekt in productie” probleem door consistente metadata-definities over omgevingen af te dwingen. Het verlaagt ook maintenance overhead doordat teams upgrades en dependencies via versies beheren in plaats van handmatig patchen.
Kortom, packaging is volwassen geworden van AppExchange-distributiemechanisme tot de ruggengraat van duurzame Salesforce-delivery.
Het gesprek is niet langer “Moeten we packages gebruiken?” maar “Hoe beginnen we, en hoe snel kunnen we migreren?”
Een paar belangrijke vragen:
Deployt je team nog handmatig via change sets of scripts?
Heb je een betrouwbare source of truth voor je metadata?
Hoe snel kun je een volledige omgeving reproduceren vanuit source?
Zijn je dependencies en integraties tracked, versioned en testable?
Kunnen developers parallel werken zonder elkaars werk te overschrijven?
Als je op een van deze vragen “nog niet” antwoordt, is het tijd om
modernisering te overwegen.
Migratie hoeft niet in één nacht te gebeuren, maar elke stap richting
source-driven, package-based delivery betaalt zich terug.
Hier lees je waarom deze verschuiving belangrijk is en hoe je haar implementeert. "The Secrets of Salesforce Second Generation Managed Package"
De technische basis is nu stevig, maar CI/CD, version control en packaging workflows opzetten kost nog steeds tijd. Hier maken oplossingen zoals Serpent by Tekunda de overgang makkelijker. Serpent stroomlijnt Salesforce DevOps door packaging, version management en deployment processes te automatiseren via een eenvoudige interface rond Git en de Salesforce CLI.
Met guided onboarding, automated release pipelines en native Git integration helpt Serpent teams van handmatige org development naar volledig geautomatiseerde delivery, zonder onnodige complexiteit toe te voegen. Voor teams die hun volgende stap in packaging evolution overwegen, is het een snelle manier om de voordelen in de praktijk te zien.
Salesforce package development heeft een lange weg afgelegd. Wat begon als niche ISV-tool is uitgegroeid tot een kernonderdeel van professionele Salesforce engineering. De vraag is niet langer of je team packaging moet gebruiken, maar hoe snel je het kunt omarmen.
Naar source control en modulaire packages bewegen is niet alleen een best practice; het is de richting waarin Salesforce zelf bouwt. Hoe eerder je aansluit, hoe sneller je releases, hoe schoner je architectuur en hoe soepeler je schaalvergroting.
Andrew Hanna
Serpent Team
Tekunda Team
Tekunda Team
Tekunda Team
Andrew Hanna