Dans beaucoup d'ETI, l'équipe Salesforce tient sur deux développeurs qui portent à la fois les évolutions, la maintenance et les mises en production. Sans processus outillé, chaque livraison devient risquée : régressions, écrasements de configuration, allers-retours manuels via change sets. Cet article explique comment structurer un cycle de livraison fiable avec des sandbox bien organisées, un pipeline CI/CD léger et l'outil DevOps Center, sans mobiliser une équipe pléthorique.
Pourquoi industrialiser les livraisons avec une petite équipe
Le réflexe intuitif est de penser que l'automatisation des déploiements ne concerne que les grandes équipes. C'est l'inverse : plus l'équipe est réduite, plus le temps perdu sur des tâches manuelles et sur la correction de régressions pèse lourd. Deux développeurs qui passent une demi-journée par semaine à préparer des change sets et à repasser des étapes de configuration à la main perdent un volume de travail significatif sur l'année.
Industrialiser ne signifie pas construire une usine complexe. Il s'agit de rendre chaque étape reproductible : savoir ce qui va partir en production, pouvoir revenir en arrière, et détecter les erreurs avant qu'elles n'atteignent les utilisateurs. L'objectif est de réduire la charge cognitive et le stress des mises en production, pas d'ajouter des couches d'outillage.
Bien organiser ses sandbox
La sandbox est le socle de toute stratégie de livraison. Salesforce propose plusieurs types de sandbox, dont les caractéristiques déterminent l'usage :
- Developer : copie de la configuration (métadonnées) uniquement, avec peu de stockage. Adaptée au travail individuel d'un développeur.
- Developer Pro : même logique avec davantage de stockage pour des jeux de données de test plus volumineux.
- Partial Copy : inclut la configuration et un échantillon de données de production, utile pour les tests d'intégration et de recette.
- Full : copie complète de la production, réservée aux tests de charge et de pré-production. Son rafraîchissement est peu fréquent.
Avec deux développeurs, une organisation lisible consiste à donner à chacun une sandbox Developer pour son travail isolé, puis à disposer d'une sandbox partagée d'intégration où les travaux se rejoignent, et enfin d'une sandbox de recette proche de la production pour valider avant le déploiement final. Ce découpage évite que le code d'un développeur n'écrase celui de l'autre.
Attention au rafraîchissement des sandbox : recréer une Full sandbox efface les développements en cours qui n'ont pas été versionnés. Sans dépôt Git comme source de vérité, un rafraîchissement mal planifié peut détruire du travail. Le versionnement n'est donc pas optionnel.
Le rôle central du versionnement Git
Le passage aux change sets manuels vers une approche outillée repose sur un principe simple : la source de vérité n'est plus l'organisation Salesforce, mais un dépôt Git. Chaque modification de configuration ou de code est décrite sous forme de métadonnées, stockée dans le dépôt, puis déployée vers les environnements.
Ce changement apporte plusieurs bénéfices concrets pour une petite équipe :
- Traçabilité : on sait qui a modifié quoi, et quand.
- Réversibilité : revenir à un état antérieur devient possible.
- Collaboration : deux développeurs peuvent travailler en parallèle et fusionner leurs travaux via des branches.
- Reproductibilité : le même ensemble de métadonnées peut être rejoué sur plusieurs sandbox.
La difficulté principale reste la gestion des métadonnées Salesforce, qui ne se comportent pas toujours comme du code applicatif classique. Certaines dépendances entre composants doivent être déployées ensemble, et tout n'est pas encore couvert par les formats de métadonnées. Une phase de cadrage est utile pour identifier ce qui sera géré par le pipeline et ce qui restera manuel.
DevOps Center : une porte d'entrée sans usine à gaz
DevOps Center est l'outil proposé par Salesforce pour gérer le cycle de vie des changements. Il s'installe comme une application dans l'organisation et ne nécessite pas de licence payante spécifique. Son intérêt pour une équipe de deux développeurs est de fournir une interface qui masque une partie de la complexité de Git et des déploiements en ligne de commande.
Concrètement, DevOps Center permet de :
- connecter les sandbox et la production à un dépôt Git ;
- suivre les modifications réalisées dans une sandbox et les regrouper en unités de travail cohérentes ;
- promouvoir ces changements d'un environnement à l'autre selon un pipeline défini ;
- garder un historique visuel de ce qui a été déployé et de ce qui est en attente.
Pour une équipe qui vient des change sets, DevOps Center représente une marche progressive vers le versionnement. Les développeurs plus à l'aise peuvent en parallèle utiliser la CLI Salesforce (SF CLI) pour les opérations avancées, tandis que l'interface reste accessible pour les manipulations courantes.
Ajouter une couche CI/CD adaptée à la taille de l'équipe
La CI/CD (intégration continue et livraison continue) ajoute l'automatisation autour du dépôt Git. À chaque contribution, un ensemble de vérifications peut être déclenché automatiquement : validation du déploiement, exécution des tests Apex, contrôles de qualité de code.
Pour deux développeurs, l'enjeu n'est pas de reproduire les pipelines complexes des grandes équipes, mais de couvrir l'essentiel :
- lancer les tests Apex à chaque fusion pour éviter les régressions ;
- valider qu'un déploiement passera avant de l'exécuter réellement ;
- déclencher le déploiement vers la recette ou la production de façon contrôlée.
Des outils comme GitHub Actions ou GitLab CI, associés à la SF CLI, suffisent souvent pour bâtir ce socle. La priorité est de garder le pipeline simple et compréhensible par les deux personnes qui l'entretiennent : un pipeline que personne ne sait réparer devient un point de fragilité plutôt qu'un atout.
Une trajectoire progressive plutôt qu'un grand chantier
Le passage à des livraisons industrialisées se fait par étapes. Une trajectoire réaliste pour une petite équipe pourrait être : d'abord clarifier l'organisation des sandbox, puis mettre le versionnement Git en place comme source de vérité, ensuite adopter DevOps Center pour promouvoir les changements, et enfin ajouter une automatisation CI/CD sur les tests et validations. Chaque étape apporte une valeur autonome et réduit le risque sans imposer une refonte globale.
Le cadrage initial est déterminant : il permet de dimensionner les outils au regard de la complexité réelle de l'organisation Salesforce, de la fréquence des livraisons et des compétences de l'équipe. Un dimensionnement excessif crée une dette de maintenance que deux développeurs ne pourront pas absorber.
Aller plus loin
Choisir un accompagnement pour cette structuration relève souvent d'une compétence spécialisée en DevOps Salesforce, distincte du développement fonctionnel. Vérifier l'expérience concrète d'un prestataire sur ce type de mise en place, et non seulement son discours, évite les déconvenues.