Migrer de Gearset vers Serpent sans interruption

En bref : aucun gel des releases n'est nécessaire. Votre dépôt Git est l'actif portable, donc les deux outils peuvent y être connectés pendant que vous basculez pipeline par pipeline, l'environnement le plus bas d'abord et la production en dernier. Ce qui se transfère : le dépôt, ses branches et son historique. Ce qui se reconstruit : tout ce qui vivait chez l'éditeur, jobs de CI et de surveillance, connexions aux orgs, portes d'approbation, planifications de sauvegarde et historique de déploiement.

Que transféré-t-on réellement lors d'une bascule ?

Le modèle mental qui simplifie tout : les métadonnées vivent dans Git, l'orchestration vit chez l'éditeur. La documentation de Gearset décrit votre dépôt comme l'endroit où les métadonnées sont stockées, l'outil se chargeant de les déplacer entre les orgs et ce dépôt. L'actif que vous avez construit pendant des années, l'historique des commits, le modèle de branches, l'arborescence, vous appartient et ne bouge pas.

Se transfère sans modification :

• Le dépôt Git, avec chaque branche, tag et commit.
• Votre arborescence et votre format de métadonnées, tant que le nouvel outil le lit.
• Les règles de protection de branche et les listes de relecteurs, puisqu'elles vivent dans GitHub, GitLab ou Bitbucket.
• Tout ce qui est déjà du code : scripts, tests Apex, configuration d'analyse statique.

Doit être reconstruit :

• Les définitions de jobs CI/CD et leurs planifications.
• Les jobs de surveillance des changements et leurs règles de notification.
• Les connexions aux orgs et les utilisateurs authentifiés, par environnement.
• Les portes d'approbation et les règles définissant qui promeut en production.
• Les planifications de sauvegarde et les données de sauvegarde conservées, qui ne sont pas portables d'un éditeur à l'autre.
• L'historique de déploiement et les enregistrements d'audit détenus par l'ancien outil.

Que vérifier avant de brancher quoi que ce soit ?

Confirmez d'abord votre format de métadonnées. Gearset commite au format source SFDX lorsqu'il initialise un dépôt vide et prend aussi en charge le format metadata API : un dépôt hérité peut donc légitimement être dans l'un ou l'autre. Une incompatibilité de format est exactement ce qui transforme une exécution parallèle tranquille en mur de faux diffs.

Si le dépôt est au format metadata API et que vous voulez convertir, faites-en un changement à part : convertir, relire, fusionner, vérifier un déploiement issu du résultat. Ne convertissez jamais le format et ne changez pas d'outil la même semaine, sinon vous ne saurez pas quelle modification a causé quelle surprise.

Comment continuer à livrer avec les deux outils connectés ?

1. Inventoriez ce que fait l'ancien outil. Déploiements, jobs CI, surveillance des changements, sauvegarde, revue de code, alimentation de sandbox. Cette liste est votre backlog de migration et elle est plus longue que dans les souvenirs de chacun.
2. Connectez le nouvel outil en lecture seule. Pointez-le sur le même dépôt et les mêmes orgs et lancez des comparaisons sans déployer. Le premier jour, rien ne change pour l'équipe.
3. Reconstruisez d'abord l'environnement le plus bas. Dev ou intégration. Laissez une squad livrer via le nouveau pipeline pendant un sprint, les autres restent sur l'ancien chemin.
4. Faites tourner les deux sur un cycle de release complet. Le nouveau pipeline valide chaque changement, l'ancien déploie encore. Chaque écart entre les deux résultats est un trou de configuration trouvé gratuitement.
5. Basculez UAT et préproduction. À ce stade la forme du pipeline est prouvée, le modèle d'approbation est acté et les sorties d'audit ressemblent à ce qu'attendent vos relecteurs.
6. Basculez la production en dernier, dans une fenêtre de changement normale. Il n'y a pas d'événement de bascule, seulement le dernier environnement qui bouge.
7. Décommissionnez avec un décalage. Gardez l'ancien abonnement au moins une période de rétention de sauvegarde, puis révoquez les connexions aux orgs et supprimez clés de déploiement et webhooks.

Quels sont les pièges d'un fonctionnement en parallèle ?

• Deux écrivains, une branche. Convenez qu'un seul outil commite sur une branche donnée à un instant donné. Les commits concurrents sont la blessure la plus auto-infligée d'une migration.
• Checks de statut en double. Les deux outils voudront publier sur les pull requests. N'en rendez qu'un obligatoire, sinon les fusions attendent un pipeline que vous retirez.
• Double déploiement. Si les deux outils ont un job planifié vers la même org cible, vous déployez deux fois. Désactivez l'ancienne planification dès que la nouvelle est en service, pas la semaine suivante.
• Sauvegardes. Les données de sauvegarde ne s'exportent généralement pas vers un autre éditeur sous une forme restaurable. Tranchez votre position de rétention avant toute résiliation.
• Trous d'audit. En environnement régulé, exportez l'historique de déploiement que vous devez conserver pendant que l'ancien contrat court encore.

Combien de temps cela prend-il ?

La contrainte est votre cadence de release, pas l'outillage. Une équipe en cycle de deux semaines s'en sort généralement en deux cycles : un cycle en parallèle et un cycle de production. La mise en place de Serpent prend moins de 15 minutes par workspace et les sessions d'onboarding avec notre équipe sont gratuites : l'essentiel du calendrier consiste à attendre vos propres fenêtres de changement.

Pourquoi les équipes changent-elles d'outil ?

Trois raisons reviennent sans cesse. Un tarif qui bouge avec les utilisateurs et avec le nombre d'orgs CI/CD. Un flux de travail qui suppose une aisance avec Git que la moitié administrateurs de l'équipe n'a pas. Et une livraison de packages vendue à part. Serpent facture à plat par entreprise, fonctionne par tickets avec Git en arrière-plan, n'installe rien dans votre org et inclut les workflows 1GP, 2GP et AppExchange sur tous les plans, y compris Essentials gratuit. La migration de données avec masquage des PII fait aussi partie de la plateforme, et Backup & Restore est inclus à partir de Scale. D'autres guides de bascule vivent dans notre bibliothèque SF Guides.

FAQ

Faut-il geler les releases pour changer d'outil ?

Non. Reconstruisez les environnements un par un et laissez l'ancien pipeline déployer jusqu'à ce que le nouveau ait validé un cycle complet.

Deux outils DevOps peuvent-ils être connectés au même dépôt ?

Oui, et c'est ce qui rend possible une bascule sans interruption. La règle qui la sécurise : un seul écrivain par branche à la fois.

Nos sauvegardes existantes sont-elles transférées ?

Non. Les données de sauvegarde ne sont pas portables sous forme restaurable, prévoyez donc un recouvrement couvrant votre exigence de rétention.

Qu'advient-il de notre historique de déploiement ?

Il reste chez l'ancien outil. Exportez ce dont vos auditeurs ont besoin tant que le contrat est actif.

Serpent installe-t-il quelque chose dans nos orgs Salesforce ?

Non. Il se connecte uniquement via les API standard : aucun package à approuver à l'entrée et rien à désinstaller ensuite.