Tous les outils DevOps Salesforce ignorent le developpement de packages

Reponse courte : la categorie du DevOps Salesforce s'est construite sur le deploiement d'org a org, ses primitives sont donc des environnements et des metadonnees, pas des artefacts versionnes. La livraison de packages, 1GP, 2GP et managed, est arrivee apres coup et se vend encore souvent comme une option. C'est pourquoi, en 2026, la plupart des ISV et des PDO publient toujours leur produit avec des scripts qu'ils ont ecrits eux-memes.

Que suppose reellement la livraison d'un package ?

Une release d'org a org est courte : constituer un lot, le valider contre la cible, le deployer. Une release de package a une tout autre forme :

1. Resoudre les dependances entre vos propres packages et ceux dont vous heritez.
2. Creer une version contre un Dev Hub, dans une scratch org, avec la bonne ancetralite pour que le chemin de mise a jour tienne.
3. Installer cette version dans des orgs de test, une par edition et configuration supportee.
4. Franchir les portes : couverture Apex, analyse statique et, pour un produit publie, la security review AppExchange.
5. Promouvoir la version en released, ce qui est irreversible.
6. Pousser ou publier vers les orgs abonnees, puis suivre qui est sur quelle version.
7. Mettre a jour la version de la fiche pour que ce que voient les clients corresponde a ce qu'ils peuvent installer.

Seule l'etape trois ressemble a un deploiement. Le reste est de la gestion d'artefacts, et un pipeline qui modelise des environnements n'a nulle part ou la mettre.

Pourquoi la categorie s'est-elle construite autour de l'org a org ?

Parce que le volume est la. L'immense majorite des equipes Salesforce exploite une org de production entouree de sandboxes, et leur probleme de release est sincerement : "faire passer ce changement de la recette a la production sans rien casser." Copado, Gearset, AutoRABIT, Flosum, Salto et Blue Canvas ont tous bati de bons produits sur ce probleme, avec le meme modele : environnements, branches, metadonnees, diffs.

Aucune de ces primitives ne contient un numero de version. Un package n'est pas un diff entre deux orgs. C'est un artefact immuable dote d'une identite, d'un ancetre et d'une population d'installations dans des orgs que vous ne controlez pas.

De quoi un pipeline de package a-t-il besoin qu'un pipeline d'org n'a pas ?

• Un artefact, pas un diff. L'unite de release est un identifiant de version, et il doit survivre bien au-dela de la branche dont il est issu.
• L'ancetralite. Un mauvais ancetre ne produit pas une mauvaise release, il produit une release impossible a mettre a jour.
• L'ordre des dependances. Un produit multi-packages s'installe dans un ordre precis, et cet ordre doit se calculer, pas se retenir.
• Les scratch orgs comme unite de test. La validation d'un package se fait dans une org neuve, de facon repetee, ce qui transforme le temps de provisionnement en cout de CI.
• Une vue abonnes. Qui est sur quelle version, chez qui une push upgrade a echoue, qui a deux versions majeures de retard et bloque une depreciation.
• Des portes de revue. La security review est une etape de release pour un produit publie, pas une corvee de conformite qui se passe ailleurs.

Pourquoi les ISV ecrivent-ils encore leurs propres scripts de release ?

Parce que c'est ce que l'ecosysteme leur indique. Cherchez comment publier un package 2GP et vous trouverez des guides pas a pas pour construire votre propre pipeline dans Azure DevOps ou GitHub Actions, en enchainant a la main sf package version create et sf package version promote. Le guide Salesforce du second-generation managed packaging le dit sans detour : les operations de packaging passent par la CLI, ou vous les automatisez avec des scripts.

C'est une bonne reponse pour une plateforme. C'est une reponse etrange pour une categorie qui vend de l'automatisation de release.

Pendant ce temps la plateforme avance. Package Migrations est devenu generalement disponible en Summer '25, avec sf package convert pour transformer une version 1GP en 2GP et une push upgrade --migrate-to-2gp qui bascule les abonnes sans reinstallation. Un editeur 1GP dispose enfin d'un vrai chemin de migration, et d'un vrai besoin de pipeline capable de comprendre les deux generations a la fois. La plupart des outils traitent encore le packaging comme une integration ajoutee.

Que casse-t-il quand le packaging est une option ?

Trois choses, et elles s'aggravent mutuellement :

• Les equipes qui en ont le plus besoin ne peuvent pas l'acheter. Un ISV de cinq personnes a le probleme de release le plus difficile de l'ecosysteme et le plus petit budget. Si le support des packages est derriere une offre entreprise, cette equipe ecrit du bash, et ces scripts deviennent un savoir tribal repose sur une seule personne.
• L'etat des releases finit dans un tableur. Quand le pipeline ne peut pas porter une version, l'ancetralite et les versions abonnes vivent dans un document que personne ne met a jour un vendredi.
• Les tests se degradent en silence. Si une scratch org met plusieurs minutes a se provisionner et que le pipeline n'a pas ete concu pour cela, quelqu'un finira par valider le package moins souvent dans une org propre. C'est precisement le test qui attrape les erreurs de packaging.

A quoi ressemblerait un support de packaging de premier rang ?

Le test est simple : le pipeline qui livre un changement d'org peut-il aussi produire une version, resoudre les dependances, installer dans une matrice de test, promouvoir et suivre les abonnes, sans sortir du produit ? Sur la meme offre, pas sur l'offre entreprise.

C'est le manque autour duquel Serpent a ete construit, ne de l'exploitation d'un ISV eHealth a travers des managed packages et la security review AppExchange. Les workflows 1GP, 2GP et managed, la resolution des dependances entre packages, la gestion des versions chez les abonnes et les workflows de release AppExchange figurent dans toutes les offres, y compris la gratuite, avec un pool de scratch orgs prechauffees sur Scale pour que la validation en org propre reste assez peu couteuse pour continuer a tourner. Voyez comment Serpent traite la livraison de packages.

FAQ

2GP est-il obligatoire, ou puis-je rester en 1GP ?

Vous pouvez rester, mais l'investissement de la plateforme va vers 2GP. Package Migrations, disponible depuis Summer '25, convertit une version 1GP et bascule les abonnes via une push upgrade.

Ne puis-je pas simplement utiliser GitHub Actions ?

Si, et beaucoup d'equipes le font. Le prix a payer, c'est que vous possedez la logique d'ancetralite, l'ordre des dependances, le suivi des abonnes et la personne qui comprend l'ensemble.

Cela ne concerne-t-il que les ISV AppExchange ?

Non. Toute equipe qui utilise des packages unlocked ou managed pour sa modularite interne rencontre les memes primitives, moins la security review.

Quelle est la partie la plus difficile d'une release de package ?

L'ancetralite et la promotion, car les deux sont irreversibles. Un mauvais ancetre casse le chemin de mise a jour de tous les abonnes, et une version promue ne se depromeut pas.