Déploiements delta dans Salesforce: ne déployer que ce qui a changé

Un déploiement delta n'envoie que les métadonnées modifiées entre deux références Git, plutôt que le projet entier. On le calcule en comparant des commits, en générant un package.xml à partir de ce diff, puis en déployant ce manifeste. C'est plus rapide et moins risqué qu'un déploiement complet sur un point précis, et plus fragile sur un autre: un paquet partiel peut échouer sur des dépendances qu'un paquet complet satisfaisait par accident.

Qu'est-ce qu'un déploiement delta dans Salesforce?

Un déploiement delta est un déploiement de métadonnées dont le manifeste provient d'un diff Git plutôt que de tout votre arbre source. Trois pièces mobiles:

• Le diff. Deux références Git, en général votre branche de feature et la branche cible de la fusion.
• Le manifeste. Un package.xml listant uniquement les composants ajoutés et modifiés, plus un destructiveChanges.xml listant suppressions et renommages.
• Le déploiement. Un déploiement de métadonnées normal contre ce manifeste.

Rien là-dedans n'appartient aux éditeurs de DevOps. Tout outil proposant du delta, Serpent compris, exécute une variante des mêmes trois étapes.

Comment calculer un paquet delta?

La voie open source courante est sfdx-git-delta, le plugin que le blog Salesforce Developers a détaillé pour les sources non packagées. À noter: c'est un plugin non officiel, maintenu par la communauté, donc traitez-le comme une dépendance qui vous appartient.

1. Assurez-vous que votre checkout CI dispose d'assez d'historique Git. Un clone superficiel de profondeur un ne peut pas se comparer à une branche de base, et c'est de loin la première cause d'un paquet delta vide ou faux.
2. Générez le manifeste: sf sgd source delta --from origin/main --to HEAD --output-dir .
3. Ajoutez --generate-delta si vous voulez extraire aussi les fichiers source modifiés. À n'utiliser que si --to vaut HEAD.
4. Protégez-vous d'un manifeste vide. Un déploiement avec un package.xml vide échoue, donc votre pipeline doit sauter l'étape plutôt que tomber en erreur.
5. Déployez en appliquant les suppressions après les ajouts: sf project deploy start -x package/package.xml --post-destructive-changes destructiveChanges/destructiveChanges.xml
6. Validez d'abord. Passez le même manifeste en déploiement check-only sur la cible avant le vrai.

Quels pièges de dépendances font échouer un déploiement delta?

C'est la partie que les tutoriels sautent. Un déploiement complet embarque tous les composants, donc les dépendances implicites se résolvent en silence. Un delta n'embarque qu'un sous-ensemble, et chaque dépendance jusque-là invisible devient une erreur.

Profils et ensembles d'autorisations

Ajoutez un champ dans le delta: son accès vit dans le profil, qui est un fichier distinct. Si ce fichier n'a pas changé, il n'est pas dans le delta, et le champ atterrit sur la cible sans que personne ne le voie. Le côté retrieve aggrave la chose: Salesforce ne renvoie que les paramètres de sécurité des types de métadonnées cités dans la requête, les permissions utilisateur, plages IP et heures de connexion étant toujours incluses. Déployez les profils délibérément, ne laissez pas le diff décider.

Listes de sélection, types d'enregistrement et traductions

Supprimer une valeur de liste de sélection touche les types d'enregistrement et les traductions qui la référencent. sfdx-hardis a ajouté le delta avec dépendances exactement pour ce cas, car l'échec n'apparaît souvent pas dans le déploiement delta. Il apparaît au déploiement complet suivant, des semaines plus tard, dans un autre pipeline.

Tests Apex

Si vous déployez une classe modifiée sous RunSpecifiedTests, sa classe de test doit exister sur la cible et figurer dans la liste des tests. Un delta qui contient la classe mais pas le test est un échec de couverture qui attend la production.

Flows

Supprimer un flow via destructiveChanges.xml est une limite documentée de la plateforme. Le contournement consiste à le désactiver d'abord en déployant un FlowDefinition avec activeVersionNumber à zéro.

Métadonnées logées dans un seul fichier

Étiquettes personnalisées, workflows et règles de correspondance regroupent de nombreux membres dans un fichier unique. Modifier une ligne marque tout le fichier comme changé, et les inclure de force exige l'historique Git complet, pas un clone superficiel.

Renommages

Git voit un renommage comme une suppression suivie d'un ajout. Déployez-les dans le mauvais ordre et vous supprimez un composant encore référencé, ou vous créez un doublon. L'ordre post-destructif existe pour cela.

Quand déployer en complet plutôt qu'en delta?

Un défaut utile, celui que livre sfdx-hardis, est: delta pour les branches de feature fusionnant vers une branche partagée, et déploiements complets entre environnements partagés. Le raisonnement: plus on remonte le pipeline, plus la cible risque d'avoir dérivé du contrôle de source, et un delta suppose que le contrôle de source dit vrai.

Passez en complet si l'un de ces points est vrai:

• L'org cible a subi des modifications manuelles depuis le dernier déploiement.
• Le changement touche largement aux profils, ensembles d'autorisations ou règles de partage.
• Vous promouvez entre deux environnements de longue durée plutôt que de fusionner une feature.
• Vous vous remettez d'un déploiement échoué ou partiellement appliqué.

Gardez une surcharge manuelle. sfdx-hardis utilise un marqueur NO_DELTA dans le titre du commit, un bon motif à reprendre quel que soit l'outillage: celui qui sait qu'un changement est risqué doit pouvoir forcer un déploiement complet sans toucher à la configuration du pipeline.

À quoi ressemble un pipeline delta sûr?

1. Clone complet, ou au moins assez de profondeur pour atteindre la base de fusion.
2. Générez le manifeste, puis affichez-le dans le journal de build pour qu'un humain lise ce qui part.
3. Sautez proprement quand le manifeste est vide.
4. Déploiement check-only, puis réel, avec les suppressions en dernier.
5. Déploiement complet planifié, chaque semaine ou à chaque release, pour rattraper la dérive que les deltas n'ont jamais touchée.

C'est cette dernière étape que les équipes abandonnent, et c'est elle qui attrape la famille de pannes listes de sélection et traductions avant qu'une release soit en jeu. D'autres playbooks de livraison Salesforce sont dans notre bibliothèque SF Guides.

FAQ

Les déploiements delta sont-ils plus sûrs que les complets?

Ils sont plus rapides et touchent moins, ce qui réduit le rayon d'impact. Ils ne sont pas intrinsèquement plus sûrs, car un paquet partiel peut manquer une dépendance qu'un paquet complet aurait portée.

Ai-je besoin de sfdx-git-delta pour faire du delta?

Non. C'est la voie open source la plus répandue, non officielle et maintenue par la communauté. La plupart des plateformes DevOps commerciales calculent le delta pour vous.

Pourquoi mon paquet delta est-il vide en CI mais pas en local?

Presque toujours un clone superficiel. Votre checkout CI a besoin d'assez d'historique Git pour atteindre le commit de référence.

Comment supprimer des métadonnées dans un déploiement delta?

Via destructiveChanges.xml, appliqué après le paquet additif. Les flows font exception: désactivez-les d'abord par un changement de FlowDefinition.

Les profils doivent-ils faire partie du delta?

Déployez-les délibérément plutôt que de laisser le diff trancher. Un fichier profil ne porte que les paramètres des types de métadonnées inclus dans le retrieve, donc un profil issu d'un diff est rarement celui que vous vouliez.