Comment changer d'outil DevOps Salesforce sans casser votre pipeline

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

La plupart des equipes Salesforce savent qu'elles ont besoin d'un meilleur outil DevOps mais retardent le changement parce que la migration semble risquee. La realite : rester sur un outil qui ne convient pas a votre equipe est plus risque. Chaque cycle de release manuel, chaque casse en production due a un change set non teste, chaque heure passee sur un travail qui devrait etre automatise - voila votre vrai cout.

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

Avant de commencer : la checklist pre-migration

• ✅ Documentez votre processus de release actuel - combien d'etapes, qui approuve, qui execute les tests
• ✅ Identifiez toutes les org connectees (sandbox, staging, UAT, production) et leurs relations
• ✅ Listez tous les types de metadonnees actifs deployes (Flows, Apex, LWC, Permission Sets, etc.)
• ✅ Notez les tests automatises deja en place et leur frequence d'execution
• ✅ Confirmez que votre depot Git est a jour (si vous etes deja sous controle de source)
• ✅ Choisissez une fenetre de migration a faible trafic - evitez la fin de mois ou les clotures trimestrielles

Migrer depuis les Change Sets

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

1. Connectez vos org. Avec Serpent, connectez toutes les org via OAuth - production, sandboxes et toute org de developpement. Cela prend 10-15 minutes.
2. Initialisez le controle de source. Si vous n'avez pas de depot Git, creez-en un. Serpent se connecte directement a GitHub, GitLab ou Bitbucket.
3. Lancez un instantane des metadonnees. Recuperez vos metadonnees de production actuelles dans le controle de source comme base de reference. C'est votre point de depart.
4. Construisez votre premier pipeline. Configurez un deploiement simple de sandbox dev → UAT → production. Executez-le une fois avec un changement petit et sur pour verifier la configuration.
5. Retirez les change sets. Apres 2-3 deploiements automatises reussis, arretez d'utiliser les change sets pour le nouveau travail. Conservez les change sets deja approuves pour le travail en cours jusqu'a leur cloture.

Delai de migration complete : 1-2 semaines pour la plupart des equipes.

Migrer depuis Gearset

Les equipes Gearset comprennent deja les pipelines et le controle de source - la migration consiste surtout a reconfigurer vos definitions de pipeline et vos connexions d'org. Encore indecis ? Notre comparatif alternative a Gearset couvre les vraies differences entre les deux plateformes.

1. Exportez votre configuration de pipeline Gearset. Documentez quelles org se connectent a quelles autres, quels filtres de metadonnees vous utilisez, et quels tests sont requis par environnement.
2. Reconnectez les org. Utilisez le meme flux OAuth pour connecter toutes les org a la nouvelle plateforme. Votre depot Git existant fonctionne tel quel.
3. Recreez les pipelines. Mappez chaque pipeline Gearset vers son equivalent dans Serpent. La plupart des configurations se traduisent directement.
4. Faites tourner en parallele pendant un sprint. Gardez Gearset actif pour les pipelines existants pendant que vous construisez et testez les nouveaux dans Serpent. Un sprint en parallele suffit a capter les ecarts.
5. Basculez. Apres un sprint sans probleme dans Serpent, desactivez les pipelines Gearset et annulez l'abonnement.

Delai de migration complete : 2-4 semaines, sprint parallele inclus.

Migrer depuis Copado

Les migrations Copado sont les plus complexes car les user stories et la gestion des branches de Copado sont profondement integrees. La cle est de migrer le processus, pas seulement l'outillage. Pour la comparaison fonctionnalite par fonctionnalite, lisez d'abord notre comparatif alternative a Copado.

1. Cloturez 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 strategie de branches. Les equipes Copado ont typiquement un modele de branching specifique - assurez-vous que votre equipe s'aligne dessus avant de changer d'outil.
3. Migrez les connexions d'org. Meme procedure OAuth que ci-dessus.
4. Reconstruisez vos etapes de pipeline. Mappez les environnements Copado vers les etapes de pipeline Serpent. Les concepts sont equivalents.
5. Reformez l'equipe. L'interface de Copado est tres familiere pour certains membres de l'equipe. Prevoyez 2-3 heures d'onboarding d'equipe.
6. Faites tourner en parallele pendant deux sprints. Vu la complexite plus elevee, faites tourner deux sprints complets en parallele avant de basculer.

Delai de migration complete : 4-8 semaines, execution parallele et reformation incluses.

Ce qu'il ne faut pas faire

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

Combien de temps cela prend-il vraiment ?

Depuis	Delai realiste	Complexite principale
Change Sets	1-2 semaines	Construire le premier pipeline depuis zero
Gearset	2-4 semaines	Recreer les configurations de pipeline
Copado	4-8 semaines	Alignement du processus et reformation de l'equipe

FAQ

Comment changer d'outil DevOps sans casser son pipeline ?

Migrez un pipeline a la fois et faites tourner l'ancien et le nouvel outil en parallele pendant au moins un sprint avant de basculer. Commencez par un seul pipeline sandbox plutot 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 ?

Prevoyez environ une a deux semaines depuis les change sets, deux a quatre semaines depuis Gearset, et quatre a huit semaines depuis Copado. Copado prend le plus de temps car le processus et les habitudes de l'equipe evoluent avec l'outillage, pas seulement la configuration.

Peut-on migrer en plein sprint ?

Mieux vaut eviter. Cloturez d'abord le travail en cours, et evitez les periodes de gel, la fin de mois et les clotures trimestrielles. Choisir une fenetre a faible trafic evite qu'une surprise ne tombe en plus d'une release.

Que preparer avant de changer d'outil DevOps ?

Documentez votre processus de release actuel et qui approuve quoi, listez chaque org connectee et leurs relations, notez les types de metadonnees que vous deployez et les tests que vous executez deja, et confirmez que votre depot Git est a jour.

Prets a commencer ?

L'equipe migration de Serpent peut realiser une evaluation de migration gratuite - nous cartographions votre configuration actuelle vers une configuration Serpent et vous donnons un delai realiste avant tout engagement. Demarrez votre migration ici.