Deploiements delta dans Salesforce: ne deployer que ce qui a change

Un deploiement delta n'envoie que les metadonnees modifiees entre deux references Git, plutot que le projet entier. On le calcule en comparant des commits, en generant un package.xml a partir de ce diff, puis en deployant ce manifeste. C'est plus rapide et moins risque qu'un deploiement complet sur un point precis, et plus fragile sur un autre: un paquet partiel peut echouer sur des dependances qu'un paquet complet satisfaisait par accident.

Qu'est-ce qu'un deploiement delta dans Salesforce?

Un deploiement delta est un deploiement de metadonnees dont le manifeste provient d'un diff Git plutot que de tout votre arbre source. Trois pieces mobiles:

• Le diff. Deux references Git, en general votre branche de feature et la branche cible de la fusion.
• Le manifeste. Un package.xml listant uniquement les composants ajoutes et modifies, plus un destructiveChanges.xml listant suppressions et renommages.
• Le deploiement. Un deploiement de metadonnees normal contre ce manifeste.

Rien la-dedans n'appartient aux editeurs de DevOps. Tout outil proposant du delta, Serpent compris, execute une variante des memes trois etapes.

Comment calculer un paquet delta?

La voie open source courante est sfdx-git-delta, le plugin que le blog Salesforce Developers a detaille pour les sources non packagees. A noter: c'est un plugin non officiel, maintenu par la communaute, donc traitez-le comme une dependance 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 a une branche de base, et c'est de loin la premiere cause d'un paquet delta vide ou faux.
2. Generez 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 modifies. A n'utiliser que si --to vaut HEAD.
4. Protegez-vous d'un manifeste vide. Un deploiement avec un package.xml vide echoue, donc votre pipeline doit sauter l'etape plutot que tomber en erreur.
5. Deployez en appliquant les suppressions apres les ajouts: sf project deploy start -x package/package.xml --post-destructive-changes destructiveChanges/destructiveChanges.xml
6. Validez d'abord. Passez le meme manifeste en deploiement check-only sur la cible avant le vrai.

Quels pieges de dependances font echouer un deploiement delta?

C'est la partie que les tutoriels sautent. Un deploiement complet embarque tous les composants, donc les dependances implicites se resolvent en silence. Un delta n'embarque qu'un sous-ensemble, et chaque dependance jusque-la invisible devient une erreur.

Profils et ensembles d'autorisations

Ajoutez un champ dans le delta: son acces vit dans le profil, qui est un fichier distinct. Si ce fichier n'a pas change, il n'est pas dans le delta, et le champ atterrit sur la cible sans que personne ne le voie. Le cote retrieve aggrave la chose: Salesforce ne renvoie que les parametres de securite des types de metadonnees cites dans la requete, les permissions utilisateur, plages IP et heures de connexion etant toujours incluses. Deployez les profils deliberement, ne laissez pas le diff decider.

Listes de selection, types d'enregistrement et traductions

Supprimer une valeur de liste de selection touche les types d'enregistrement et les traductions qui la referencent. sfdx-hardis a ajoute le delta avec dependances exactement pour ce cas, car l'echec n'apparait souvent pas dans le deploiement delta. Il apparait au deploiement complet suivant, des semaines plus tard, dans un autre pipeline.

Tests Apex

Si vous deployez une classe modifiee 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 echec de couverture qui attend la production.

Flows

Supprimer un flow via destructiveChanges.xml est une limite documentee de la plateforme. Le contournement consiste a le desactiver d'abord en deployant un FlowDefinition avec activeVersionNumber a zero.

Metadonnees logees dans un seul fichier

Etiquettes personnalisees, workflows et regles de correspondance regroupent de nombreux membres dans un fichier unique. Modifier une ligne marque tout le fichier comme change, 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. Deployez-les dans le mauvais ordre et vous supprimez un composant encore reference, ou vous creez un doublon. L'ordre post-destructif existe pour cela.

Quand deployer en complet plutot qu'en delta?

Un defaut utile, celui que livre sfdx-hardis, est: delta pour les branches de feature fusionnant vers une branche partagee, et deploiements complets entre environnements partages. Le raisonnement: plus on remonte le pipeline, plus la cible risque d'avoir derive du controle de source, et un delta suppose que le controle 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 deploiement.
• Le changement touche largement aux profils, ensembles d'autorisations ou regles de partage.
• Vous promouvez entre deux environnements de longue duree plutot que de fusionner une feature.
• Vous vous remettez d'un deploiement echoue ou partiellement applique.

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

A quoi ressemble un pipeline delta sur?

1. Clone complet, ou au moins assez de profondeur pour atteindre la base de fusion.
2. Generez 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. Deploiement check-only, puis reel, avec les suppressions en dernier.
5. Deploiement complet planifie, chaque semaine ou a chaque release, pour rattraper la derive que les deltas n'ont jamais touchee.

C'est cette derniere etape que les equipes abandonnent, et c'est elle qui attrape la famille de pannes listes de selection et traductions avant qu'une release soit en jeu. D'autres playbooks de livraison Salesforce sont dans notre bibliotheque SF Guides.

FAQ

Les deploiements delta sont-ils plus surs que les complets?

Ils sont plus rapides et touchent moins, ce qui reduit le rayon d'impact. Ils ne sont pas intrinsequement plus surs, car un paquet partiel peut manquer une dependance qu'un paquet complet aurait portee.

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

Non. C'est la voie open source la plus repandue, non officielle et maintenue par la communaute. 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 reference.

Comment supprimer des metadonnees dans un deploiement delta?

Via destructiveChanges.xml, applique apres le paquet additif. Les flows font exception: desactivez-les d'abord par un changement de FlowDefinition.

Les profils doivent-ils faire partie du delta?

Deployez-les deliberement plutot que de laisser le diff trancher. Un fichier profil ne porte que les parametres des types de metadonnees inclus dans le retrieve, donc un profil issu d'un diff est rarement celui que vous vouliez.