Migrer de Copado vers Serpent : le guide pas a pas

Reponse courte : vous n'avez pas besoin d'un gel de code, et vous ne migrez aucune donnee. Vos metadonnees vivent deja dans Git, donc passer de Copado a Serpent est un changement de plan de controle : vous reconstruisez la definition du pipeline, faites tourner les deux outils en parallele sur un cycle de release complet, puis laissez le nouveau pipeline prendre la promotion en production pendant que l'ancien reste installe comme filet de securite. Raisonnez en cycles de release, pas en jours calendaires.

Qu'est-ce qui bouge reellement, et qu'est-ce qui reste ?

Etre precis la-dessus enleve l'essentiel de l'inquietude :

• Rien n'a besoin d'etre migre. Votre source de verite est votre depot Git, et il reste exactement ou il est, historique compris.
• Ce qui reste derriere, ce sont les enregistrements qui n'existent que dans un managed package : user stories, promotions, enregistrements de deploiement et toute l'automatisation batie dessus. Copado est installe dans votre org, ces objets partent donc avec le package.
• Ce que vous reconstruisez, c'est la definition du pipeline : environnements et identifiants, ordre des etapes, regles d'approbation, portes qualite, taches planifiees et l'integration au ticketing.

Cette derniere liste, c'est tout le projet. C'est du travail de configuration, et c'est pourquoi il s'agit d'un exercice de correspondance plutot que d'une migration.

Comment les concepts Copado se traduisent-ils dans un pipeline Git-natif ?

Copado modelise la release dans des enregistrements Salesforce. Un pipeline Git-natif la modelise dans le depot. La traduction est presque terme a terme :

• User Story devient un work item rattache a une branche.
• La branche de feature par user story reste une branche de feature. Vous pouvez conserver la convention de nommage pour que l'historique se lise sans rupture.
• La promotion et sa branche de promotion deviennent une pull request vers la branche de l'environnement suivant.
• L'enregistrement de deploiement devient une execution de pipeline, avec son journal, son resultat et son point de retour.
• L'environnement ou l'etape devient un environnement associe a une branche.
• La retro-promotion devient une fusion descendante depuis la branche superieure.
• Les portes de conformite et de qualite deviennent des controles de pull request : tests, analyse statique, revue de code par IA.

Quel est le deroule pas a pas ?

1. Inventaire, un a deux jours. Listez chaque environnement, branche, etape, approbateur, tache planifiee, porte qualite et integration, avec un responsable en face. Si une etape n'a pas de responsable, voila votre premier constat.
2. Dupliquez le pipeline en lecture seule. Connectez les memes orgs et le meme depot a Serpent sans rien deployer. La connexion prend quelques minutes. Comparez ensuite : les deux outils sont-ils d'accord sur ce que contient chaque environnement ? Tout desaccord est une derive que vous portiez deja.
3. Doublez une release. Chaque changement passe par Copado comme d'habitude, et aussi par le nouveau pipeline vers une sandbox de reserve. Comparez les plans de deploiement. Les ecarts deviennent votre liste de constats, et concernent le plus souvent les profils, les permission sets et les flows.
4. Faites une vraie release en parallele. Le nouveau pipeline promeut vers la recette, l'ancien prend encore la production. C'est le point median maitrise, et c'est la que les approbateurs prennent confiance.
5. Basculez. Le nouveau pipeline execute la promotion en production. Laissez Copado installe et intact : c'est votre retour arriere, car si la promotion echoue, la release suivante repasse par lui.
6. Demantelez apres deux releases propres. Exportez l'historique, desactivez d'abord les anciennes taches planifiees, puis desinstallez le managed package dans une sandbox avant de toucher a la production.

Que faire de l'historique des user stories ?

C'est la question qui bloque les migrations, et la reponse honnete est : n'essayez pas de l'importer.

• Les enregistrements historiques n'ont de sens que dans l'outil qui les a crees. Des user stories importees sans pipeline vivant derriere sont decoratives, et induiront quelqu'un en erreur dans un an.
• Exportez plutot. User stories, promotions et deploiements en CSV, avec la reference de commit lorsqu'elle existe. Rangez cela ou vivent vos autres preuves de release.
• L'historique durable, c'est Git. Commits, pull requests, fusions et tags sont ce que les auditeurs acceptent reellement, et tout ce qui suit la bascule y atterrit par defaut.
• Pour la continuite d'audit, conservez l'export et les liens de commit. Une archive datee et une branche tracable valent mieux que des captures d'ecran d'un systeme desactive.

Comment gerer la strategie de branches ?

Changez une chose a la fois. L'outil d'abord, le processus ensuite.

Conservez votre modele de branches au moins pendant les deux premieres releases, meme si vous comptez le simplifier. Les branches d'environnement de longue duree continuent de fonctionner, les branches de promotion sont remplacees une pour une par des pull requests, et si vous visez le trunk-based, faites-en un chantier separe apres la bascule. Le point de vigilance pendant le parallele, c'est la collision d'automatisations : desactivez les taches planifiees et les fusions automatiques de l'ancien outil avant que le nouveau pipeline n'ecrive sur les memes branches.

Comment eviter l'interruption et le gel de code ?

• Gelez la configuration du pipeline, pas le travail. Pendant le parallele, personne ne modifie les etapes, les approbations ni les regles de branche, dans aucun des deux outils.
• Placez la bascule en debut de sprint, jamais en fin, et jamais sur un week-end de release.
• Ecrivez le retour arriere avant d'en avoir besoin. Une phrase : si la promotion en production echoue sur le nouveau pipeline, la suivante repasse par l'ancien outil et les deux restent connectes une release de plus.
• Ne gardez les deux outils connectes que quelques releases. Deux systemes qui ecrivent indefiniment sur les memes branches ne sont pas un filet de securite, mais un conflit de fusion programme.

La duree depend des cycles de release, pas de l'installation. Connecter orgs et depots se fait dans la journee, et l'accompagnement Serpent comprend une session pratique pour toute l'equipe, sans frais, de sorte que la correspondance du pipeline se fait avec vous plutot que d'etre remise comme une tache. D'autres guides DevOps Salesforce.

FAQ

Faut-il un gel de code pour changer d'outil ?

Non. L'outil existant reste installe et fait foi jusqu'a la release de bascule, le developpement continue donc sans interruption.

Peut-on garder notre depot Git et nos noms de branches ?

Oui. Le depot n'est pas touche, et conserver le nommage existant permet a l'historique de se lire sans rupture.

Que deviennent nos user stories a la desinstallation du package ?

Elles partent avec lui, d'ou l'export CSV prealable. Les commits, pull requests et tags dans Git demeurent, et c'est la piste d'audit durable.

Combien de temps dure la migration complete ?

Raisonnez en cycles : un cycle en doublon, un cycle en parallele, un cycle de bascule. Pour un pipeline d'org a org standard, cela se compte en semaines, essentiellement passees a attendre vos propres releases.

Peut-on migrer de la meme facon un pipeline de package ou d'ISV ?

Oui, avec un cycle supplementaire. Versions de package, ancetralite et suivi des abonnes meritent leur propre release en doublon avant que vous ne fassiez confiance a la bascule.