Resolution des dependances entre packages Salesforce : modelisation, ordre d'installation et upgrades surs

Reponse courte : la resolution des dependances entre packages, c'est la facon dont Salesforce determine quels packages doivent deja etre presents, et dans quelles versions, avant qu'un autre puisse s'installer ou se mettre a jour. Vous la declarez dans le tableau dependencies de sfdx-project.json, dans l'ordre d'installation. Avec le bon ordre et les bons planchers de version, les upgrades chez les abonnes sont ennuyeux. Sinon, une org se retrouve sur une version qu'elle ne peut plus quitter.

Qu'est-ce qu'une dependance de package, exactement ?

Il y a dependance des que des metadonnees d'un package referencent celles d'un autre : un Flow sur un objet manage, une classe Apex qui etend une classe de base, un field set sur le champ de quelqu'un d'autre. La consequence concrete est une precondition. Le package reference doit etre installe d'abord, dans une version au moins aussi recente que celle contre laquelle vous avez construit, faute de quoi l'installation echoue.

Comment declarer une dependance entre packages ?

Dans l'entree de package directory de sfdx-project.json, sous l'une des deux formes :

• Un alias qui porte deja la version : { "package": "[email protected]" }
• Le package et la version separement : { "package": "MyPackage", "versionNumber": "1.0.0.RELEASED" }

Trois regles comptent plus que la syntaxe.

• L'ordre est l'ordre d'installation. Quand un package a plusieurs dependances, la liste se lit comme la sequence dans laquelle elles doivent etre installees.
• Les dependances circulaires ne sont pas supportees. A qui depend de B pendant que B depend de A n'est pas une enigme a resoudre, c'est une conception a decouper.
• Les chaines a plusieurs niveaux sont supportees. C peut dependre de B, et B de A. Avec "calculateTransitiveDependencies": true vous ne declarez que les dependances directes, les indirectes etant calculees. Sans cela, il faut lister chaque niveau a la main, indefiniment.

Quels types de packages peuvent dependre de quels autres ?

Cela contraint l'architecture : verifiez-le avant de la dessiner.

• Un managed 2GP peut dependre d'un managed 2GP et d'un package unlocked.
• Un managed 2GP ne peut pas dependre d'un managed 1GP. Salesforce bloque l'installation de packages managed 2GP dans les orgs de packaging managed 1GP. Si un produit l'exige vraiment, la voie est une demande d'exception individuelle aupres du Salesforce Partner Support, pas une astuce dans un script de build.
• Un managed 1GP peut dependre d'un managed 1GP, d'un managed 2GP et d'un package unlocked.
• Un package unlocked dependant de packages manages est deconseille, et rien de supporte ne depend d'un package unmanaged.

Un package de base 1GP sous une extension 2GP est la conception de dependance la plus frequemment defaite trop tard, et elle coute cher a ce stade. Lisez les combinaisons supportees avant le premier build, pas apres.

Comment modeliser les packages pour garder un graphe peu profond ?

1. Une seule direction. Base, puis fonctionnalite, puis peripherie. Si deux packages veulent se referencer, les metadonnees communes appartiennent a un troisieme package situe en dessous.
2. Petit et modulaire vaut mieux qu'un gros package. La creation et l'installation sont plus rapides, et vous atteignez moins vite les limites.
3. La profondeur coute, pas la largeur. Chaque niveau ajoute multiplie la coordination de release : un changement tout en bas exige une nouvelle version a chaque niveau au-dessus avant qu'un abonne n'en voie quoi que ce soit.
4. Epinglez deliberement. Un numero de build epingle est reproductible et ennuyeux. Un mot-cle comme RELEASED suit votre derniere version publiee, ce qui est pratique en developpement et surprenant dans un build de release.

Quel est le bon ordre d'installation dans une org abonnee ?

1. Installez ou mettez a jour d'abord le package le plus bas du graphe, celui qui n'a aucune dependance.
2. Remontez niveau par niveau, pour que chaque package trouve sa precondition satisfaite au moment de s'installer.
3. Installez en dernier le package terminal, celui que votre client a reellement achete.
4. Verifiez au lieu de supposer. Une requete SOQL sur SubscriberPackageVersion indique ce qui est installe dans cette org et dans quelle version, ce qui vaut mieux que de lire la page Installed Packages en esperant.

Si vous ne savez pas enoncer cet ordre de memoire pour votre propre produit, votre equipe support ne le saura pas non plus au moment ou un client est bloque.

Comment changer une dependance sans bloquer les abonnes ?

• La nouvelle version doit etre un descendant direct de celle installee. Les abonnes ne peuvent pas sauter la lignee : un package dont l'ancestry est cassee est un package que certaines orgs ne pourront pas mettre a jour.
• Les packages beta ne sont pas upgradables. Un abonne qui detient une beta doit desinstaller avant d'installer une version released, ce qui en production devient une conversation sur la perte de donnees. Ne laissez jamais une beta dans une org client.
• Les metadonnees retirees sont depreciees ou supprimees lors de l'upgrade. Deplacer un composant d'un package a un autre est un retrait ici et un ajout la : l'ordre de release entre les deux constitue tout le risque.
• Relevez les planchers de version une marche a la fois. Faire bondir de plusieurs releases la version requise d'un package de base impose une chaine de mises a jour a des abonnes qui n'en prevoyaient aucune.

La sequence qui fonctionne quand un package de base change : publiez la nouvelle version de base, amenez-y les abonnes via une version recommandee ou un push upgrade, puis publiez le package dependant qui l'exige. Inverser ces deux etapes produit un upgrade qui echoue sur une precondition, dans une org que vous ne voyez pas et que vous ne pouvez pas reparer de votre cote.

Que faut-il automatiser ?

1. Construire le graphe depuis sfdx-project.json a chaque execution du pipeline et faire echouer le build sur un cycle.
2. Installer toute la chaine dans une scratch org propre, dans l'ordre declare, a chaque fois, pour que les erreurs d'ordre apparaissent au build et non chez un client.
3. Enregistrer les versions installees par org abonnee, pour que le support reponde a la question avant de la poser au client.

Serpent gere la resolution des dependances entre packages, les workflows 1GP, 2GP et managed package et la gestion des versions a travers les orgs abonnees sur toutes les formules, y compris la gratuite. D'autres playbooks de packaging sont dans notre bibliotheque SF Guides.

FAQ

Un package managed 2GP peut-il dependre d'un managed 1GP ?

Pas par defaut. Salesforce bloque la combinaison, et une exception individuelle se demande via une demande aupres du Salesforce Partner Support.

Dois-je lister les dependances transitives ?

Seulement si vous le souhaitez. Avec "calculateTransitiveDependencies": true, vous declarez les dependances directes et les indirectes sont calculees. Sans cela, chaque niveau doit etre liste a la main.

Que se passe-t-il si deux packages dependent l'un de l'autre ?

Rien de bon, car les dependances circulaires ne sont pas supportees. Extrayez les metadonnees communes dans un package inferieur dont les deux dependent.

Quel package mettre a jour en premier dans une org abonnee ?

Le plus bas du graphe. Les dependances passent avant les packages qui les exigent, dans l'ordre meme de l'installation.

Pourquoi l'upgrade de mon client echoue-t-il avec une erreur de dependance ?

En general un plancher de version. Le package de base installe est plus ancien que ce qu'exige votre nouvelle release : mettez d'abord le package de base a jour, puis reessayez.