Tous les outils DevOps Salesforce ignorent le développement de packages

Réponse courte : la catégorie du DevOps Salesforce s'est construite sur le déploiement d'org à org, ses primitives sont donc des environnements et des métadonnées, pas des artefacts versionnés. La livraison de packages, 1GP, 2GP et managed, est arrivée après 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 écrits eux-mêmes.

Que suppose réellement la livraison d'un package ?

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

1. Résoudre les dépendances entre vos propres packages et ceux dont vous héritez.
2. Créer une version contre un Dev Hub, dans une scratch org, avec la bonne ancetralite pour que le chemin de mise à jour tienne.
3. Installer cette version dans des orgs de test, une par édition et configuration supportée.
4. Franchir les portes : couverture Apex, analyse statique et, pour un produit publié, la security review AppExchange.
5. Promouvoir la version en released, ce qui est irréversible.
6. Pousser ou publier vers les orgs abonnées, puis suivre qui est sur quelle version.
7. Mettre à jour la version de la fiche pour que ce que voient les clients corresponde à ce qu'ils peuvent installer.

Seule l'étape trois ressemble à un déploiement. Le reste est de la gestion d'artefacts, et un pipeline qui modélise des environnements n'a nulle part où la mettre.

Pourquoi la catégorie s'est-elle construite autour de l'org à org ?

Parce que le volume est là. L'immense majorité des équipes Salesforce exploite une org de production entourée de sandboxes, et leur problème de release est sincèrement : "faire passer ce changement de la recette à la production sans rien casser." Copado, Gearset, AutoRABIT, Flosum, Salto et Blue Canvas ont tous bâti de bons produits sur ce problème, avec le même modèle : environnements, branches, métadonnées, diffs.

Aucune de ces primitives ne contient un numéro de version. Un package n'est pas un diff entre deux orgs. C'est un artefact immuable doté d'une identité, d'un ancêtre et d'une population d'installations dans des orgs que vous ne contrôlez 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'unité de release est un identifiant de version, et il doit survivre bien au-delà de la branche dont il est issu.
• L'ancetralite. Un mauvais ancêtre ne produit pas une mauvaise release, il produit une release impossible à mettre à jour.
• L'ordre des dépendances. Un produit multi-packages s'installe dans un ordre précis, et cet ordre doit se calculer, pas se retenir.
• Les scratch orgs comme unité de test. La validation d'un package se fait dans une org neuve, de façon répétée, ce qui transforme le temps de provisionnement en coût de CI.
• Une vue abonnés. Qui est sur quelle version, chez qui une push upgrade a échoué, qui a deux versions majeures de retard et bloque une dépréciation.
• Des portes de revue. La security review est une étape de release pour un produit publié, pas une corvée de conformité qui se passe ailleurs.

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

Parce que c'est ce que l'écosystème leur indique. Cherchez comment publier un package 2GP et vous trouverez des guides pas à pas pour construire votre propre pipeline dans Azure DevOps ou GitHub Actions, en enchaînant à la main sf package version create et sf package version promote. Le guide Salesforce du second-generation managed packaging le dit sans détour : les opérations de packaging passent par la CLI, ou vous les automatisez avec des scripts.

C'est une bonne réponse pour une plateforme. C'est une réponse étrange pour une catégorie qui vend de l'automatisation de release.

Pendant ce temps la plateforme avance. Package Migrations est devenu généralement 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 abonnés sans réinstallation. Un éditeur 1GP dispose enfin d'un vrai chemin de migration, et d'un vrai besoin de pipeline capable de comprendre les deux générations à la fois. La plupart des outils traitent encore le packaging comme une intégration ajoutée.

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

Trois choses, et elles s'aggravent mutuellement :

• Les équipes qui en ont le plus besoin ne peuvent pas l'acheter. Un ISV de cinq personnes a le problème de release le plus difficile de l'écosystème et le plus petit budget. Si le support des packages est derrière une offre entreprise, cette équipe écrit du bash, et ces scripts deviennent un savoir tribal repose sur une seule personne.
• L'état des releases finit dans un tableur. Quand le pipeline ne peut pas porter une version, l'ancetralite et les versions abonnés vivent dans un document que personne ne met à jour un vendredi.
• Les tests se dégradent en silence. Si une scratch org met plusieurs minutes à se provisionner et que le pipeline n'a pas été conçu pour cela, quelqu'un finira par valider le package moins souvent dans une org propre. C'est précisément le test qui attrape les erreurs de packaging.

À 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, résoudre les dépendances, installer dans une matrice de test, promouvoir et suivre les abonnés, sans sortir du produit ? Sur la même offre, pas sur l'offre entreprise.

C'est le manque autour duquel Serpent a été construit, ne de l'exploitation d'un ISV eHealth à travers des managed packages et la security review AppExchange. Les workflows 1GP, 2GP et managed, la résolution des dépendances entre packages, la gestion des versions chez les abonnés et les workflows de release AppExchange figurent dans toutes les offres, y compris la gratuite, avec un pool de scratch orgs préchauffées sur Scale pour que la validation en org propre reste assez peu coûteuse pour continuer à 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 abonnés via une push upgrade.

Ne puis-je pas simplement utiliser GitHub Actions ?

Si, et beaucoup d'équipes le font. Le prix à payer, c'est que vous possédez la logique d'ancetralite, l'ordre des dépendances, le suivi des abonnés et la personne qui comprend l'ensemble.

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

Non. Toute équipe qui utilise des packages unlocked ou managed pour sa modularité interne rencontre les mêmes 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 irréversibles. Un mauvais ancêtre casse le chemin de mise à jour de tous les abonnés, et une version promue ne se dépromeut pas.