Andrew Hanna
Andrew Hanna
Lorsque Salesforce a introduit packaging, ce n'était pas vu comme une stratégie de développement. C'était une façon de regrouper des composants pour la distribution, surtout pour les ISV construisant des apps pour AppExchange.
La plupart des équipes internes s'appuyaient encore sur change sets, déploiements manuels et outils de metadata migration. Le concept de développement modulaire et versionné était loin de la réalité.
Avec le temps, l'écosystème Salesforce a fortement changé. Ce qui a commencé comme une fonction optionnelle pour un petit groupe d'ISV est devenu un pilier central de la façon dont les équipes Salesforce engineering modernes construisent, déploient et maintiennent leurs systèmes.
Comprendre ce parcours explique pourquoi packaging n'est plus seulement “nice to have”; c'est la base du développement scalable.
Avant Salesforce DX, le développement se faisait directement dans les orgs. Les équipes construisaient dans des sandboxes, utilisaient change sets ou ANT scripts pour déployer les métadonnées et n'avaient souvent aucune source of truth unique. Les first-generation managed packages (1GP) permettaient aux ISV de distribuer des applications et protéger leur propriété intellectuelle, mais avec de fortes contraintes.
La création de packages et le versioning étaient liés à la packaging org. Le code vivait dans l'org et les développeurs géraient les dépendances manuellement. Il n'y avait pas de lien réel avec Git ou CI/CD, ce qui rendait la collaboration lente et fragile.
Pour la plupart des équipes Salesforce internes, packaging semblait excessif. Elles restaient sur des déploiements directs parce que c'était plus rapide, du moins jusqu'à ce que les systèmes deviennent trop grands.
Le tournant est venu avec Salesforce DX (SFDX) et la Salesforce CLI. Cela a introduit une approche developer-first : source-driven development, scratch orgs et version control externe. Pour la première fois, l'org n'était plus la source of truth.
Ce changement a redéfini la création et la maintenance des packages. Les métadonnées pouvaient être extraites, stockées dans Git et déployées de façon cohérente via des pipelines automatisés. Salesforce a introduit les unlocked packages pour clients et partenaires, conçus pour diviser les grandes orgs monolithiques en composants plus petits et modulaires évoluant indépendamment.
Ils ont aidé les équipes à passer progressivement du développement org traditionnel sans tout refactorer d'un coup.
Si vous avez toujours construit directement dans les orgs, c'est ici que le changement devient logique. Vous n'avez pas besoin de tout déplacer en une nuit. Vous pouvez commencer petit, packager une feature, un module ou un business process, et commencer à le suivre dans source control.
Avez-vous déjà voulu revenir en arrière sans perdre des heures de travail ? Ou voir exactement ce qui a changé entre deux releases ? Ou déployer avec confiance en sachant que chaque dépendance est prise en compte ? C'est ce que permettent les org-dependent unlocked packages.
Ils permettent d'adopter versioning, développement modulaire et pratiques CI/CD sans casser votre structure existante. Pas de refactor massif. Pas de migration metadata complète. Seulement un chemin pratique du développement basé sur l'org au développement moderne source-driven.
Ces étapes ont marqué une direction claire : Salesforce voulait que chaque équipe, pas seulement les ISV, avance vers une delivery modulaire et source-controlled à un rythme réaliste.
L'introduction des second-generation managed packages (2GP) a consolidé cette évolution. Au lieu de tout construire et gérer dans une seule packaging org, les développeurs pouvaient créer des packages depuis leur source locale, les versionner avec Git et les publier via la CLI.
C'était un changement majeur. Packaging devenait compatible avec les outils CI/CD, les tests automatisés et les pratiques modernes. 2GP améliorait aussi la gestion des dépendances, des namespaces et de la sécurité, tout en s'alignant sur la manière dont les plateformes SaaS gèrent les releases.
Aujourd'hui, second-generation packaging est le chemin par défaut pour les nouveaux ISV et de plus en plus pour les équipes enterprise qui veulent des workflows de développement maintenables et scalables. Salesforce continue d'investir dans ces outils, du modèle DevHub et des scratch orgs à l'interface DevOps Center qui abstrait une grande partie du travail CLI pour les admins.
Pendant des années, packaging était considéré comme optionnel, quelque chose à adopter seulement quand l'org atteignait une certaine taille ou complexité. Cette vision devient vite dépassée. La réalité est que chaque équipe Salesforce, interne ou commerciale, gagne à utiliser source control et packages versionnés.
Les avantages vont au-delà de la vitesse de déploiement. Le source-driven development garantit reproductibilité, audit plus simple et releases plus sûres. Il élimine le problème “ça marche en sandbox mais casse en production” en imposant des définitions metadata cohérentes entre environnements. Il réduit aussi l'overhead de maintenance en gérant upgrades et dépendances par versions plutôt que par patches manuels.
En bref, packaging est passé d'un mécanisme de distribution AppExchange à la colonne vertébrale d'une delivery Salesforce durable.
La conversation n'est plus “Devons-nous utiliser des packages ?” mais “Comment commencer, et à quelle vitesse migrer ?”
Quelques questions clés :
Votre équipe déploie-t-elle encore manuellement via change sets ou scripts ?
Avez-vous une source of truth fiable pour vos métadonnées ?
À quelle vitesse pouvez-vous reproduire un environnement complet depuis la source ?
Vos dépendances et intégrations sont-elles tracked, versioned et testable ?
Vos développeurs peuvent-ils travailler en parallèle sans écraser le travail des autres ?
Si votre réponse est “pas encore”, il est temps de penser à moderniser.
La migration n'a pas besoin de se faire en une nuit, mais chaque pas
vers une delivery source-driven et package-based paie.
Voici ce qu'il faut savoir sur l'importance et l'implémentation de ce changement. "The Secrets of Salesforce Second Generation Managed Package"
La base technique est solide, mais mettre en place CI/CD, version control et packaging workflows prend encore du temps. C'est là que des solutions comme Serpent by Tekunda facilitent la transition. Serpent simplifie Salesforce DevOps en automatisant packaging, version management et deployment processes via une interface simple construite autour de Git et Salesforce CLI.
Avec guided onboarding, automated release pipelines et native Git integration, Serpent aide les équipes à passer du développement org manuel à une delivery entièrement automatisée, sans complexité inutile. Pour les équipes qui envisagent leur prochaine étape, c'est une façon rapide de voir les bénéfices en pratique.
Le développement de packages Salesforce a beaucoup évolué. Ce qui a commencé comme un outil ISV de niche est devenu une partie centrale de l'ingénierie Salesforce professionnelle. La question n'est plus de savoir si votre équipe devrait utiliser packaging, mais à quelle vitesse vous pouvez l'adopter.
Avancer vers source control et des packages modulaires n'est pas seulement une best practice; c'est la direction que Salesforce construit elle-même. Plus vous vous alignez tôt, plus vos releases seront rapides, votre architecture propre et votre scaling fluide.
Andrew Hanna
Serpent Team
Tekunda Team
Tekunda Team
Tekunda Team
Andrew Hanna