Migrer de Copado vers Serpent : le guide pas à pas

Réponse courte : vous n'avez pas besoin d'un gel de code, et vous ne migrez aucune donnée. Vos métadonnées vivent déjà dans Git, donc passer de Copado à Serpent est un changement de plan de contrôle : vous reconstruisez la définition du pipeline, faites tourner les deux outils en parallèle sur un cycle de release complet, puis laissez le nouveau pipeline prendre la promotion en production pendant que l'ancien reste installé comme filet de sécurité. Raisonnez en cycles de release, pas en jours calendaires.

Qu'est-ce qui bouge réellement, et qu'est-ce qui reste ?

Être précis là-dessus enlève l'essentiel de l'inquiétude :

• Rien n'a besoin d'être migré. Votre source de vérité est votre dépôt Git, et il reste exactement où il est, historique compris.
• Ce qui reste derrière, ce sont les enregistrements qui n'existent que dans un managed package : user stories, promotions, enregistrements de déploiement et toute l'automatisation bâtie dessus. Copado est installé dans votre org, ces objets partent donc avec le package.
• Ce que vous reconstruisez, c'est la définition du pipeline : environnements et identifiants, ordre des étapes, règles d'approbation, portes qualité, tâches planifiées et l'intégration au ticketing.

Cette dernière liste, c'est tout le projet. C'est du travail de configuration, et c'est pourquoi il s'agit d'un exercice de correspondance plutôt que d'une migration.

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

Copado modélise la release dans des enregistrements Salesforce. Un pipeline Git-natif la modélise dans le dépôt. La traduction est presque terme à terme :

• User Story devient un work item rattaché à 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 déploiement devient une exécution de pipeline, avec son journal, son résultat et son point de retour.
• L'environnement ou l'étape devient un environnement associé à une branche.
• La rétro-promotion devient une fusion descendante depuis la branche supérieure.
• Les portes de conformité et de qualité deviennent des contrôles de pull request : tests, analyse statique, revue de code par IA.

Quel est le déroulé pas à pas ?

1. Inventaire, un à deux jours. Listez chaque environnement, branche, étape, approbateur, tâche planifiée, porte qualité et intégration, avec un responsable en face. Si une étape n'a pas de responsable, voilà votre premier constat.
2. Dupliquez le pipeline en lecture seule. Connectez les mêmes orgs et le même dépôt à Serpent sans rien déployer. La connexion prend quelques minutes. Comparez ensuite : les deux outils sont-ils d'accord sur ce que contient chaque environnement ? Tout désaccord est une dérive que vous portiez déjà.
3. Doublez une release. Chaque changement passe par Copado comme d'habitude, et aussi par le nouveau pipeline vers une sandbox de réserve. Comparez les plans de déploiement. Les écarts deviennent votre liste de constats, et concernent le plus souvent les profils, les permission sets et les flows.
4. Faites une vraie release en parallèle. Le nouveau pipeline promeut vers la recette, l'ancien prend encore la production. C'est le point médian maîtrisé, et c'est là que les approbateurs prennent confiance.
5. Basculez. Le nouveau pipeline exécute la promotion en production. Laissez Copado installé et intact : c'est votre retour arrière, car si la promotion échoue, la release suivante repasse par lui.
6. Démantelez après deux releases propres. Exportez l'historique, désactivez d'abord les anciennes tâches planifiées, puis désinstallez le managed package dans une sandbox avant de toucher à la production.

Que faire de l'historique des user stories ?

C'est la question qui bloque les migrations, et la réponse honnête est : n'essayez pas de l'importer.

• Les enregistrements historiques n'ont de sens que dans l'outil qui les a créés. Des user stories importées sans pipeline vivant derrière sont décoratives, et induiront quelqu'un en erreur dans un an.
• Exportez plutôt. User stories, promotions et déploiements en CSV, avec la référence de commit lorsqu'elle existe. Rangez cela où vivent vos autres preuves de release.
• L'historique durable, c'est Git. Commits, pull requests, fusions et tags sont ce que les auditeurs acceptent réellement, et tout ce qui suit la bascule y atterrit par défaut.
• Pour la continuité d'audit, conservez l'export et les liens de commit. Une archive datée et une branche traçable valent mieux que des captures d'écran d'un système désactivé.

Comment gérer la stratégie de branches ?

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

Conservez votre modèle de branches au moins pendant les deux premières releases, même si vous comptez le simplifier. Les branches d'environnement de longue durée continuent de fonctionner, les branches de promotion sont remplacées une pour une par des pull requests, et si vous visez le trunk-based, faites-en un chantier séparé après la bascule. Le point de vigilance pendant le parallèle, c'est la collision d'automatisations : désactivez les tâches planifiées et les fusions automatiques de l'ancien outil avant que le nouveau pipeline n'écrive sur les mêmes branches.

Comment éviter l'interruption et le gel de code ?

• Gelez la configuration du pipeline, pas le travail. Pendant le parallèle, personne ne modifie les étapes, les approbations ni les règles de branche, dans aucun des deux outils.
• Placez la bascule en début de sprint, jamais en fin, et jamais sur un week-end de release.
• Écrivez le retour arrière avant d'en avoir besoin. Une phrase : si la promotion en production échoue sur le nouveau pipeline, la suivante repasse par l'ancien outil et les deux restent connectés une release de plus.
• Ne gardez les deux outils connectés que quelques releases. Deux systèmes qui écrivent indéfiniment sur les mêmes branches ne sont pas un filet de sécurité, mais un conflit de fusion programme.

La durée dépend des cycles de release, pas de l'installation. Connecter orgs et dépôts se fait dans la journée, et l'accompagnement Serpent comprend une session pratique pour toute l'équipe, sans frais, de sorte que la correspondance du pipeline se fait avec vous plutôt que d'être remise comme une tâche. D'autres guides DevOps Salesforce.

FAQ

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

Non. L'outil existant reste installé et fait foi jusqu'à la release de bascule, le développement continue donc sans interruption.

Peut-on garder notre dépôt Git et nos noms de branches ?

Oui. Le dépôt n'est pas touché, et conserver le nommage existant permet à l'historique de se lire sans rupture.

Que deviennent nos user stories à la désinstallation du package ?

Elles partent avec lui, d'où l'export CSV préalable. Les commits, pull requests et tags dans Git demeurent, et c'est la piste d'audit durable.

Combien de temps dure la migration complète ?

Raisonnez en cycles : un cycle en doublon, un cycle en parallèle, un cycle de bascule. Pour un pipeline d'org à org standard, cela se compte en semaines, essentiellement passées à attendre vos propres releases.

Peut-on migrer de la même façon un pipeline de package ou d'ISV ?

Oui, avec un cycle supplémentaire. Versions de package, ancetralite et suivi des abonnés méritent leur propre release en doublon avant que vous ne fassiez confiance à la bascule.