Migrer de Gearset vers Serpent sans interruption

En bref : aucun gel des releases n'est necessaire. Votre depot Git est l'actif portable, donc les deux outils peuvent y etre connectes pendant que vous basculez pipeline par pipeline, l'environnement le plus bas d'abord et la production en dernier. Ce qui se transfere : le depot, ses branches et son historique. Ce qui se reconstruit : tout ce qui vivait chez l'editeur, jobs de CI et de surveillance, connexions aux orgs, portes d'approbation, planifications de sauvegarde et historique de deploiement.

Que transfere-t-on reellement lors d'une bascule ?

Le modele mental qui simplifie tout : les metadonnees vivent dans Git, l'orchestration vit chez l'editeur. La documentation de Gearset decrit votre depot comme l'endroit ou les metadonnees sont stockees, l'outil se chargeant de les deplacer entre les orgs et ce depot. L'actif que vous avez construit pendant des annees, l'historique des commits, le modele de branches, l'arborescence, vous appartient et ne bouge pas.

Se transfere sans modification :

• Le depot Git, avec chaque branche, tag et commit.
• Votre arborescence et votre format de metadonnees, tant que le nouvel outil le lit.
• Les regles de protection de branche et les listes de relecteurs, puisqu'elles vivent dans GitHub, GitLab ou Bitbucket.
• Tout ce qui est deja du code : scripts, tests Apex, configuration d'analyse statique.

Doit etre reconstruit :

• Les definitions de jobs CI/CD et leurs planifications.
• Les jobs de surveillance des changements et leurs regles de notification.
• Les connexions aux orgs et les utilisateurs authentifies, par environnement.
• Les portes d'approbation et les regles definissant qui promeut en production.
• Les planifications de sauvegarde et les donnees de sauvegarde conservees, qui ne sont pas portables d'un editeur a l'autre.
• L'historique de deploiement et les enregistrements d'audit detenus par l'ancien outil.

Que verifier avant de brancher quoi que ce soit ?

Confirmez d'abord votre format de metadonnees. Gearset commite au format source SFDX lorsqu'il initialise un depot vide et prend aussi en charge le format metadata API : un depot herite peut donc legitimement etre dans l'un ou l'autre. Une incompatibilite de format est exactement ce qui transforme une execution parallele tranquille en mur de faux diffs.

Si le depot est au format metadata API et que vous voulez convertir, faites-en un changement a part : convertir, relire, fusionner, verifier un deploiement issu du resultat. Ne convertissez jamais le format et ne changez pas d'outil la meme semaine, sinon vous ne saurez pas quelle modification a cause quelle surprise.

Comment continuer a livrer avec les deux outils connectes ?

1. Inventoriez ce que fait l'ancien outil. Deploiements, 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 meme depot et les memes orgs et lancez des comparaisons sans deployer. Le premier jour, rien ne change pour l'equipe.
3. Reconstruisez d'abord l'environnement le plus bas. Dev ou integration. 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 deploie encore. Chaque ecart entre les deux resultats est un trou de configuration trouve gratuitement.
5. Basculez UAT et preproduction. A ce stade la forme du pipeline est prouvee, le modele d'approbation est acte et les sorties d'audit ressemblent a ce qu'attendent vos relecteurs.
6. Basculez la production en dernier, dans une fenetre de changement normale. Il n'y a pas d'evenement de bascule, seulement le dernier environnement qui bouge.
7. Decommissionnez avec un decalage. Gardez l'ancien abonnement au moins une periode de retention de sauvegarde, puis revoquez les connexions aux orgs et supprimez cles de deploiement et webhooks.

Quels sont les pieges d'un fonctionnement en parallele ?

• Deux ecrivains, une branche. Convenez qu'un seul outil commite sur une branche donnee a un instant donne. Les commits concurrents sont la blessure la plus auto-infligee 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 deploiement. Si les deux outils ont un job planifie vers la meme org cible, vous deployez deux fois. Desactivez l'ancienne planification des que la nouvelle est en service, pas la semaine suivante.
• Sauvegardes. Les donnees de sauvegarde ne s'exportent generalement pas vers un autre editeur sous une forme restaurable. Tranchez votre position de retention avant toute resiliation.
• Trous d'audit. En environnement regule, exportez l'historique de deploiement 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 equipe en cycle de deux semaines s'en sort generalement en deux cycles : un cycle en parallele 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 equipe sont gratuites : l'essentiel du calendrier consiste a attendre vos propres fenetres de changement.

Pourquoi les equipes 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 moitie administrateurs de l'equipe n'a pas. Et une livraison de packages vendue a part. Serpent facture a plat par entreprise, fonctionne par tickets avec Git en arriere-plan, n'installe rien dans votre org et inclut les workflows 1GP, 2GP et AppExchange sur tous les plans, y compris Essentials gratuit. D'autres guides de bascule vivent dans notre bibliotheque SF Guides.

FAQ

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

Non. Reconstruisez les environnements un par un et laissez l'ancien pipeline deployer jusqu'a ce que le nouveau ait valide un cycle complet.

Deux outils DevOps peuvent-ils etre connectes au meme depot ?

Oui, et c'est ce qui rend possible une bascule sans interruption. La regle qui la securise : un seul ecrivain par branche a la fois.

Nos sauvegardes existantes sont-elles transferees ?

Non. Les donnees de sauvegarde ne sont pas portables sous forme restaurable, prevoyez donc un recouvrement couvrant votre exigence de retention.

Qu'advient-il de notre historique de deploiement ?

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 a approuver a l'entree et rien a desinstaller ensuite.