Intégration continue Salesforce : par où commencer quand on est une PME

Le problème des déploiements manuels

Dans beaucoup de PME, les évolutions Salesforce passent en production par des ensembles de modifications (change sets), préparés à la main. Tant que l'organisation est petite et qu'une seule personne la fait évoluer, cela tient. Puis les intervenants se multiplient, et les mêmes incidents apparaissent :

les oublis : un champ, une autorisation ou un flow manquant, découvert après la mise en production ;
les régressions : une évolution en écrase une autre, faite en parallèle par quelqu'un d'autre ;
aucun historique : impossible de savoir qui a changé quoi, quand, et pourquoi ;
aucun retour arrière simple : revenir à la version précédente revient à refaire le travail à l'envers ;
les suppressions : un ensemble de modifications ne sait pas supprimer un composant, il faut le faire à la main dans chaque environnement.

L'intégration continue répond à ces cinq problèmes.

Ce que veut dire « intégration continue » pour Salesforce

Concrètement, trois choses :

La configuration et le code sont stockés dans Git, l'outil de gestion de versions utilisé par tous les développeurs. Champs, objets, flows, règles de validation, code Apex, composants : tout ce qui se déploie est versionné.
Les déploiements sont faits par une chaîne automatisée, avec l'outil en ligne de commande de Salesforce (Salesforce CLI), et non plus à la main.
Chaque modification est vérifiée avant d'arriver en production : tests Apex lancés automatiquement, déploiement « à blanc » sur un environnement de recette, relecture par un pair.

Pas besoin d'un outillage lourd pour commencer : un dépôt Git et une chaîne d'automatisation (GitHub Actions, GitLab CI, Azure DevOps…) suffisent. Des outils du marché comme Gearset ou Copado ajoutent du confort ; ils ne sont pas indispensables pour démarrer.

Une mise en place en cinq étapes

1. Récupérer l'existant dans Git

On extrait la configuration et le code de la production dans un dépôt Git. C'est la photo de départ : à partir de là, tout changement laisse une trace.

2. Définir les environnements et le chemin vers la production

Un schéma simple suffit pour une PME : une ou plusieurs sandboxes de développement, une sandbox de recette, la production. Une branche Git par environnement, et une seule règle : rien n'arrive en production sans être passé par la recette.

3. Automatiser les vérifications

À chaque demande de fusion, la chaîne vérifie automatiquement la modification : contrôle de la qualité du code, lancement des tests Apex, déploiement de validation sur la recette. Si quelque chose casse, on le sait avant la production, pas après.

4. Déployer en production de façon maîtrisée

Salesforce permet de valider un déploiement en production sans l'appliquer, tests compris, puis de le lancer en quelques minutes au moment choisi (déploiement rapide). La mise en production devient une opération courte et prévisible, et non plus une soirée à risque. Rappel utile : la production exige qu'au moins 75 % du code Apex soit couvert par des tests.

5. Fixer des règles d'équipe simples

toute modification passe par une demande de fusion relue par une autre personne ;
les sandboxes sont rafraîchies régulièrement ;
la procédure de retour arrière est écrite et testée ;
personne ne modifie la production à la main, sauf urgence documentée.

Les pièges à éviter

Vouloir tout versionner dès le premier jour. Commencer par ce qui change le plus souvent (objets, flows, code), puis élargir.
Les profils. Ils sont difficiles à déployer proprement ; les ensembles d'autorisations (permission sets) sont plus simples à gérer en intégration continue.
Les données. L'intégration continue gère la configuration, pas les données : les données de référence demandent leur propre procédure.
Les modifications faites directement en production. Elles finissent par écraser, ou être écrasées par, la version de Git. Il faut les interdire, ou les rapatrier aussitôt.

Ce que l'on gagne

Des mises en production plus fréquentes et moins stressantes, un historique complet, des régressions repérées avant la production, et une équipe qui peut grandir sans que chacun marche sur le travail des autres. La mise en place et l'amélioration de chaînes d'intégration continue Salesforce font partie de nos missions, avec toujours le même objectif : livrer plus souvent sans fragiliser la production.

Questions fréquentes

Est-ce utile si nous n'avons presque pas de code ?

Oui. Les flows, les champs, les règles de validation et les mises en page sont aussi des éléments de configuration : ils se versionnent et se déploient de la même façon. C'est même là que les oublis sont les plus fréquents.

Faut-il un développeur à temps plein pour la maintenir ?

Non. Une fois en place, la chaîne tourne seule. Elle demande un peu d'attention lors des mises à jour de Salesforce ou quand on ajoute un nouvel environnement.

Par quoi commencer demain ?

Par l'étape 1 : mettre la production dans Git. Même sans automatisation, avoir l'historique de chaque changement change déjà la donne.

Notre approche

Nous mettons en place des chaînes d'intégration continue adaptées à la taille de l'équipe, et nous formons les personnes qui les utiliseront. Pour faire le point sur vos déploiements : diagnostic gratuit de 30 minutes. Voir aussi notre offre d'intégration continue Salesforce.