Comment mettre en place la rétro-promotion dans un pipeline DevOps Salesforce

Réponse courte : la rétro-promotion est la fusion qui ramène un changement de production vers chaque branche et chaque org situés plus bas dans votre pipeline. Elle est nécessaire parce qu'un correctif appliqué directement en production n'existe nulle part ailleurs : la prochaine livraison ordinaire l'écrase en silence. La façon sûre de l'automatiser est une fusion en cascade, un environnement à la fois, ouverte en pull request plutôt que poussée par un script.

Qu'est-ce que la rétro-promotion dans un pipeline Salesforce ?

Une promotion normale fait remonter un changement : dev vers integration, puis uat, puis main. La rétro-promotion va dans l'autre sens : elle prend ce qui existe déjà dans un environnement supérieur et le fusionne vers le bas, pour que les environnements inférieurs correspondent.

Deux choses doivent voyager, et la plupart des équipes n'en font qu'une :

• Le code source. Fusionnez la branche haute dans la branche basse, pour que le dépôt soit cohérent avec lui-même.
• L'org. Déployez cette fusion dans la sandbox inférieure, sinon votre prochain travail sera construit sur des métadonnées qui ne correspondent plus à la production.

Pourquoi les correctifs ont-ils besoin d'un chemin de retour vers le bas ?

Parce qu'un correctif casse l'hypothèse sur laquelle repose votre pipeline : la production ne reçoit que ce qui est monté par la chaîne. Cassez cette hypothèse et trois défaillances suivent.

• Régression silencieuse. La livraison suivante déploie l'ancienne version du même composant et le correctif disparaît. Rien n'échoue, donc personne ne le voit avant que l'incident ne se répète.
• UAT non fiable. Vous testez contre un état dans lequel la production n'est plus.
• Conflits cumulatifs. Chaque jour où les branches restent éloignées, la fusion finale devient plus grosse et plus manuelle.

Les changements hors circuit ne sont pas que des correctifs. Une mise en page modifiée en production pendant un incident, une valeur de liste ajoutée pour le support, un champ créé pour débloquer un utilisateur : tous ont besoin du même chemin de retour.

Qu'est-ce qui crée vraiment le chaos de fusion, et comment l'éviter ?

C'est la partie que la plupart des guides sautent. La rétro-promotion échoue de façon prévisible, et cinq règles évitent presque tout.

1. Fusionnez vers le bas, ne faites pas de cherry-pick. Un cherry-pick crée un nouveau commit avec un hash différent : Git considère toujours l'original comme non fusionné et fait resurgir le même conflit à chaque fusion suivante. Fusionnez la branche.
2. Descendez d'un cran à la fois, dans l'ordre du pipeline. main dans uat, puis uat dans integration, puis integration dans dev. Fusionner main directement dans dev laisse les branches sautées en conflit plus tard.
3. Lancez-la le jour même où le correctif part. La divergence coûte peu en heures et cher en semaines.
4. Ouvrez une pull request, ne poussez pas. Une automatisation qui fusionne en silence supprime la revue et la piste d'audit, les deux choses dont un correctif a le plus besoin.
5. Échouez bruyamment en cas de conflit, et assignez-le à l'auteur du correctif. C'est lui qui a le contexte. Un conflit confié à la personne de permanence se résout au jugé.

La rétro-promotion n'est pas un problème de déploiement. C'est un problème d'hygiène de branches qui se manifeste en problème de déploiement trois semaines plus tard.

Comment mettre en place la rétro-promotion, étape par étape ?

1. Écrivez l'ordre du pipeline. Une liste ordonnée des environnements et de la branche associée à chacun. Sans elle, la rétro-promotion n'a aucun sens.
2. Donnez aux correctifs leur propre branche issue de la production. Partez de main, jamais de dev, pour que le correctif n'emporte rien de non livré.
3. Faites passer le correctif par les portes habituelles. Mêmes tests, même revue, même approbation, simplement un chemin plus court.
4. Déclenchez la cascade à la fusion dans main. Le pipeline ouvre automatiquement une pull request de rétro-promotion vers la branche immédiatement inférieure.
5. Déployez chaque branche fusionnée dans son org. La parité du code sans parité de l'org laisse la dérive exactement où elle était.
6. Vérifiez par un contrôle de dérive. Comparez chaque org inférieur à sa branche une fois la cascade terminée. Une différence signifie qu'une modification a été faite dans l'org sans jamais être committée.
7. Consignez-le sur le work item. Un correctif n'est pas terminé quand la production est réparée. Il l'est quand chaque environnement le porte.

Un rafraîchissement de sandbox remplace-t-il la rétro-promotion ?

Non, et le croire est une erreur fréquente et coûteuse. Un rafraîchissement remplace la sandbox par une copie de la production, ce qui fait bien descendre le correctif, et détruit au passage tout changement non livré présent dans cette sandbox. Les rafraîchissements sont aussi rationnés : une sandbox Full ne peut être rafraîchie que tous les 29 jours (Salesforce Help), c'est donc un événement planifié, pas une réponse à incident.

Servez-vous des rafraîchissements pour réinitialiser les données et la dérive de long terme. Servez-vous de la rétro-promotion pour aligner code et orgs entre deux. La plupart des plateformes DevOps Salesforce prennent en charge cette logique sous une forme ou une autre, dont Copado, Gearset, AutoRABIT, Flosum, Blue Canvas et Salto. Ce qui varie, c'est le caractère automatique de la cascade et son arrivée sous forme de pull request révisable.

FAQ

Quelle différence entre promotion et rétro-promotion ?

La promotion fait remonter un changement vers la production. La rétro-promotion fait redescendre un changement déjà présent en haut, pour que les environnements inférieurs cessent de dériver.

La rétro-promotion doit-elle être entièrement automatique ?

Le déclencheur et la pull request, oui. La fusion elle-même doit rester approuvée, car un conflit résolu sans revue est exactement la façon dont un correctif est annulé deux fois.

Comment gérer un conflit pendant la rétro-promotion ?

Résolvez-le dans la branche de rétro-promotion, en faveur du comportement de production, et faites confirmer par l'auteur du correctif. Ne résolvez jamais en reprenant la branche basse en bloc.

La rétro-promotion est-elle utile si personne ne modifie la production directement ?

Oui, mais moins souvent. Les branches de release à longue durée de vie, les livraisons annulées et les versions correctives de packages placent tous des changements en haut que le bas n'a pas.

D'autres playbooks pas à pas se trouvent dans la bibliothèque SF Guides. Si votre pipeline n'ouvre pas encore la cascade pour vous, commencez par la règle deux : un cran à la fois, dans l'ordre. La rétro-promotion cesse alors d'être la tâche dont personne ne veut.