Comment changer d'outil DevOps Salesforce sans casser votre pipeline

Pourquoi les équipes retardent le changement (et pourquoi c'est une erreur)

La plupart des équipes Salesforce savent qu'elles ont besoin d'un meilleur outil DevOps mais retardent le changement parce que la migration semble risquée. La réalité : rester sur un outil qui ne convient pas à votre équipe est plus risqué. Chaque cycle de release manuel, chaque casse en production due à un change set non testé, chaque heure passée sur un travail qui devrait être automatisé - voilà votre vrai coût.

Ce guide explique comment changer d'outil DevOps Salesforce en toute sécurité, que vous veniez des Change Sets, de Copado ou de Gearset.

Vous n'avez pas encore choisi l'outil cible ? Notre comparatif des meilleurs outils Salesforce DevOps met dix plateformes côte à côte sur le prix, l'usage et l'approche.

Avant de commencer : la checklist pré-migration

• ✅ Documentez votre processus de release actuel - combien d'étapes, qui approuve, qui exécute les tests
• ✅ Identifiez toutes les org connectées (sandbox, staging, UAT, production) et leurs relations
• ✅ Listez tous les types de métadonnées actifs déployés (Flows, Apex, LWC, Permission Sets, etc.)
• ✅ Notez les tests automatisés déjà en place et leur fréquence d'exécution
• ✅ Confirmez que votre dépôt Git est à jour (si vous êtes déjà sous contrôle de source)
• ✅ Choisissez une fenêtre de migration à faible trafic - évitez la fin de mois ou les clôtures trimestrielles

Migrer depuis les Change Sets

Les change sets sont le point de départ le plus courant. Bonne nouvelle : cette migration est la plus propre car il n'y a pas de configuration d'outil antérieure à reprendre.

1. Connectez vos org. Avec Serpent, connectez toutes les org via OAuth - production, sandboxes et toute org de développement. Cela prend 10-15 minutes.
2. Initialisez le contrôle de source. Si vous n'avez pas de dépôt Git, créez-en un. Serpent se connecte directement à GitHub, GitLab ou Bitbucket.
3. Lancez un instantané des métadonnées. Récupérez vos métadonnées de production actuelles dans le contrôle de source comme base de référence. C'est votre point de départ.
4. Construisez votre premier pipeline. Configurez un déploiement simple de sandbox dev → UAT → production. Exécutez-le une fois avec un changement petit et sur pour vérifier la configuration.
5. Retirez les change sets. Après 2-3 déploiements automatisés réussis, arrêtez d'utiliser les change sets pour le nouveau travail. Conservez les change sets déjà approuvés pour le travail en cours jusqu'à leur clôture.

Délai de migration complète : 1-2 semaines pour la plupart des équipes.

Migrer depuis Gearset

Les équipes Gearset comprennent déjà les pipelines et le contrôle de source - la migration consiste surtout à reconfigurer vos définitions de pipeline et vos connexions d'org. Encore indécis ? Notre comparatif alternative à Gearset couvre les vraies différences entre les deux plateformes.

1. Exportez votre configuration de pipeline Gearset. Documentez quelles org se connectent à quelles autres, quels filtres de métadonnées vous utilisez, et quels tests sont requis par environnement.
2. Reconnectez les org. Utilisez le même flux OAuth pour connecter toutes les org à la nouvelle plateforme. Votre dépôt Git existant fonctionne tel quel.
3. Recréez les pipelines. Mappez chaque pipeline Gearset vers son équivalent dans Serpent. La plupart des configurations se traduisent directement.
4. Faites tourner en parallèle pendant un sprint. Gardez Gearset actif pour les pipelines existants pendant que vous construisez et testez les nouveaux dans Serpent. Un sprint en parallèle suffit à capter les écarts.
5. Basculez. Après un sprint sans problème dans Serpent, désactivez les pipelines Gearset et annulez l'abonnement.

Délai de migration complète : 2-4 semaines, sprint parallèle inclus.

Migrer depuis Copado

Les migrations Copado sont les plus complexes car les user stories et la gestion des branches de Copado sont profondément intégrées. La clé est de migrer le processus, pas seulement l'outillage. Pour la comparaison fonctionnalité par fonctionnalité, lisez d'abord notre comparatif alternative à Copado.

1. Clôturez le travail en cours. Terminez toutes les user stories Copado actives avant de commencer la migration. Ne migrez pas en plein sprint.
2. Documentez votre stratégie de branches. Les équipes Copado ont typiquement un modèle de branching spécifique - assurez-vous que votre équipe s'aligne dessus avant de changer d'outil.
3. Migrez les connexions d'org. Même procédure OAuth que ci-dessus.
4. Reconstruisez vos étapes de pipeline. Mappez les environnements Copado vers les étapes de pipeline Serpent. Les concepts sont équivalents.
5. Reformez l'équipe. L'interface de Copado est très familière pour certains membres de l'équipe. Prévoyez 2-3 heures d'onboarding d'équipe.
6. Faites tourner en parallèle pendant deux sprints. Vu la complexité plus élevée, faites tourner deux sprints complets en parallèle avant de basculer.

Délai de migration complète : 4-8 semaines, exécution parallèle et reformation incluses.

Ce qu'il ne faut pas faire

• ❌ Ne migrez pas pendant une période de gel ou avant une release majeure
• ❌ Ne sautez pas le sprint parallèle - il capte les cas limites auxquels vous n'aviez pas pensé
• ❌ Ne migrez pas toutes les org d'un coup - commencez par un seul pipeline sandbox
• ❌ N'oubliez pas de mettre à jour vos webhooks CI/CD (GitHub Actions, etc.) pour pointer vers la nouvelle plateforme

Combien de temps cela prend-il vraiment ?

Depuis	Délai réaliste	Complexité principale
Change Sets	1-2 semaines	Construire le premier pipeline depuis zéro
Gearset	2-4 semaines	Recréer les configurations de pipeline
Copado	4-8 semaines	Alignement du processus et reformation de l'équipe

FAQ

Comment changer d'outil DevOps sans casser son pipeline ?

Migrez un pipeline à la fois et faites tourner l'ancien et le nouvel outil en parallèle pendant au moins un sprint avant de basculer. Commencez par un seul pipeline sandbox plutôt que toutes les org d'un coup, et repointez vos webhooks CI/CD au passage.

Combien de temps prend une migration d'outil DevOps Salesforce ?

Prévoyez environ une à deux semaines depuis les change sets, deux à quatre semaines depuis Gearset, et quatre à huit semaines depuis Copado. Copado prend le plus de temps car le processus et les habitudes de l'équipe évoluent avec l'outillage, pas seulement la configuration.

Peut-on migrer en plein sprint ?

Mieux vaut éviter. Clôturez d'abord le travail en cours, et évitez les périodes de gel, la fin de mois et les clôtures trimestrielles. Choisir une fenêtre à faible trafic évite qu'une surprise ne tombe en plus d'une release.

Que préparer avant de changer d'outil DevOps ?

Documentez votre processus de release actuel et qui approuve quoi, listez chaque org connectée et leurs relations, notez les types de métadonnées que vous déployez et les tests que vous exécutez déjà, et confirmez que votre dépôt Git est à jour.

Prêts à commencer ?

L'équipe migration de Serpent peut réaliser une évaluation de migration gratuite - nous cartographions votre configuration actuelle vers une configuration Serpent et vous donnons un délai réaliste avant tout engagement. Démarrez votre migration ici.