Déployer des custom metadata types sans casser les abonnés

Réponse courte : Décidez qui possède chaque champ avant la première release, car ce choix est difficile à défaire. Rendez subscriber editable les valeurs que les clients ajusteront, gardez upgradeable les valeurs dont dépend votre code, considérez les valeurs de picklist et les noms d'enregistrements protégés comme définitifs, et testez chaque mise à niveau sur une org qui contient déjà des modifications client.

Que signifie « casser les abonnés » pour les custom metadata ?

Une mise à niveau de custom metadata casse un abonné de trois façons :

• Elle écrase une valeur que le client a ajustée. Sa configuration revient discrètement à zéro lors de la mise à niveau.
• Elle échoue à l'installation ou à l'upload. La plateforme rejette un changement, comme une valeur de picklist supprimée.
• Elle retire quelque chose encore utilisé. Un enregistrement dont dépend votre code ou sa configuration devient obsolète ou disparaît.

Les trois cas remontent à des choix de packaging faits avant la première release, pas à la commande de déploiement. Le chemin sûr commence donc par la définition du type.

Quel réglage de gestion des champs choisir ?

Chaque champ d'un custom metadata type packagé porte l'un de trois réglages, comme l'explique l'unité Trailhead de Salesforce sur la protection des custom metadata :

• Upgradeable (contrôlé par le développeur) : vous pouvez modifier la valeur via les mises à niveau du package. Les abonnés ne peuvent pas la modifier.
• Subscriber editable : l'abonné peut modifier la valeur après installation, et les mises à niveau du package n'écrasent pas ses changements.
• Locked : ni vous ni l'abonné ne pouvez modifier le champ après la release.

Règle pratique : si un client voudra un jour ajuster la valeur, rendez-la subscriber editable et acceptez de ne plus pouvoir la corriger dans son org. Si la valeur détermine le comportement de votre code, gardez-la upgradeable. Réservez locked aux valeurs qui ne doivent jamais bouger. Attention : les champs subscriber editable sur des enregistrements protégés sont verrouillés après la release, alors planifiez protection et gestion ensemble.

Qu'est-ce qui devient définitif après la release ?

• Les valeurs de picklist sont en ajout seul. Le guide d'implémentation des custom metadata de Salesforce indique que les développeurs peuvent ajouter des valeurs à un champ picklist packagé, mais pas les supprimer ni les désactiver, et que les abonnés ne peuvent rien y changer. Un champ picklist contenant des valeurs inactives bloque aussi l'upload du package jusqu'à ce que vous les supprimiez ou les réactiviez.
• Les noms d'enregistrements protégés sont figés. Selon la référence Metadata API, le developer name d'un enregistrement protégé ne peut plus être modifié après la release. Nommez vos enregistrements comme une API publique.
• La protection ne fait que s'assouplir. Un type protégé peut devenir public, mais un type public ne peut pas redevenir protégé. Les types protégés ne peuvent être créés que dans des orgs Developer Edition et scratch.
• Vous seul ajoutez des champs. Les abonnés ne peuvent pas ajouter de champs personnalisés à un custom metadata type géré, alors définissez les champs avant de livrer.

Que deviennent les enregistrements retirés d'un package ?

Dans les packages gérés de deuxième génération, les enregistrements custom metadata retirés sont marqués comme obsolètes (deprecated) s'ils sont visibles par l'org abonnée, et supprimés définitivement sinon, selon le guide Salesforce sur le retrait de composants de métadonnées des packages 2GP. Les composants obsolètes restent en place jusqu'à ce qu'un administrateur abonné les supprime, et le Setup Audit Trail consigne ce que la mise à niveau a retiré. Deux conséquences :

• Ne supposez pas qu'un enregistrement retiré a disparu. Un enregistrement visible peut subsister comme obsolète dans l'org abonnée : le code doit cesser d'y faire référence plutôt que de compter sur son absence.
• Ne réutilisez jamais un nom retiré. Salesforce documente une mise à niveau en échec parce qu'un composant obsolète resté en place entrait en conflit avec un composant réajouté portant le même nom.

Si vous repensez votre modèle de packages, notre guide pour changer d'outil DevOps Salesforce sans casser votre pipeline montre comment préserver l'historique des packages lors d'un changement d'outil.

Comment déployer une mise à niveau custom metadata en toute sécurité ?

1. Relisez le type, pas seulement les enregistrements. Les changements de gestion, de protection et de picklist sont irréversibles : signalez-les dans la pull request.
2. Packagez des valeurs par défaut, pas la configuration client. Livrez les enregistrements que vous devez posséder. Laissez les valeurs propres à chaque client aux champs subscriber editable ou aux enregistrements que les abonnés créent eux-mêmes.
3. Montez une org de test de mise à niveau. Installez la version publiée précédente, modifiez des valeurs subscriber editable et créez quelques enregistrements client, puis installez la nouvelle version par-dessus.
4. Vérifiez ce qui a survécu. Les modifications de l'abonné doivent être intactes, les valeurs upgradeable mises à jour, et les enregistrements retirés obsolètes et sans référence.
5. Ne modifiez des enregistrements depuis Apex que via la Metadata API. Apex ne peut pas utiliser de DML sur les enregistrements custom metadata. Il les déploie de façon asynchrone avec Metadata.Operations.enqueueDeployment et une classe Metadata.DeployCallback, et Salesforce limite le nombre de ces déploiements en file d'attente simultanément.
6. Tenez compte du cache. Les enregistrements custom metadata sont mis en cache après la première lecture, et les requêtes déjà en cours pendant une mise à jour ne voient pas les nouvelles valeurs. Les contrôles post-installation ne doivent pas attendre un changement instantané.

Quand deux branches modifient le même enregistrement .md-meta.xml, suivez notre guide pour résoudre les conflits de fusion de métadonnées Salesforce sans perdre le travail de personne.

Est-ce important si vous ne livrez pas de package géré ?

Oui, dans une moindre mesure. Les équipes internes déploient elles aussi des enregistrements custom metadata entre sandboxes et production, et déployer un enregistrement depuis la source écrase la copie de l'org cible. Si les administrateurs ajustent des enregistrements directement en production, le prochain déploiement depuis Git les réinitialise sans bruit. Faites de Git le seul endroit où ces enregistrements changent, ou excluez du déploiement les enregistrements gérés par les administrateurs. Notre guide pour permettre aux administrateurs de déployer sans toucher à Git montre comment leur offrir un chemin suivi plutôt que des modifications directes.

Où se situe Serpent ?

Serpent est la plateforme DevOps Salesforce développée par Tekunda. Elle déploie les custom metadata via le même pipeline relu que le reste de vos métadonnées, avec revue de code par IA et approbation humaine avant la production, pour qu'un changement de gestion ou de picklist soit vérifié par une deuxième paire d'yeux avant de partir. Comparez les offres Serpent, ou parcourez d'autres SF Guides sur le packaging et le CI/CD.

FAQ

Une mise à niveau de package écrase-t-elle les valeurs custom metadata des abonnés ?

Seulement sur les champs upgradeable. Les mises à niveau n'écrasent jamais une valeur qu'un abonné a modifiée dans un champ subscriber editable.

Puis-je supprimer une valeur de picklist d'un custom metadata type packagé ?

Non. Après la release, vous pouvez ajouter des valeurs, mais pas supprimer ni désactiver celles qui existent.

Apex peut-il mettre à jour des enregistrements custom metadata ?

Oui, mais pas en DML. Utilisez Metadata.Operations.enqueueDeployment, qui déploie de façon asynchrone et rend compte via une classe de callback.

Qui développe Serpent ?

Tekunda développe Serpent, une plateforme DevOps Salesforce avec CI/CD, revue de code par IA et déploiements approuvés par un humain.