Dans cet article, nous aborderons ce qui touche au déploiement sur Salesforce :
- Pourquoi réaliser des déploiements sur Salesforce ?
- Quelles sont les bonnes pratiques de déploiement ?
- Quelles sont les différentes méthodes de déploiement ?
- Comment choisir votre méthode de déploiement ?
Pourquoi réaliser des déploiements sur Salesforce ?
Pourquoi gérer des déploiements en production sur Salesforce ? Vous demandez-vous pourquoi il est nécessaire de réaliser vos mises à jour d’abord en Sandbox puis de les déployer en Production ? En effet, il arrive que des modifications soient très simples à faire, alors on pourrait les réaliser directement en production, n’est-ce pas 😉 ?
Alors pourquoi le fait de proposer des mises à jour « en prod » exaspère généralement les experts de la solution Salesforce ? Pourquoi cela ne fait pas partie des bonnes pratiques ? Pourquoi doit-on passer par un environnement de test d’abord, puis de passer par la case « déploiement » Salesforce ?
La raison est plutôt simple : pour pouvoir identifier les bugs liés aux modifications de la configuration et les résoudre sans affecter la Production, et donc les utilisateurs de la solution. En effet, sauf si vous êtes en phase d’implémentation « from scratch » de votre CRM Salesforce, vous avez des utilisateurs qui sont connectés à l’application. Vous avez des données sur votre CRM, bref, il tourne ! Généralement, ce sont des utilisateurs « front office » donc, en relation avec les clients (Sales, Customer Support, Marketing…) qui sont connectés à Salesforce. Il serait dommage de faire une mise à jour en production, même modifier une valeur de picklist (liste déroulante) et que cela ne soit finalement pas la bonne pour les utilisateurs, ou pire, que cela vienne écraser la donnée déjà enregistrée.
Ainsi, le but est que l’environnement de production fonctionne toujours sans aucun bug, et que le business puisse continuer sans interruption de service.
Quelles sont les bonnes pratiques de déploiement Salesforce ?
Dans les bonnes pratiques, il est nécessaire de séparer l’environnement où les développements sont réalisés et l’environnement où les utilisateurs vont faire leur recette métier.
On a donc besoin a minima de développer nos fonctionnalités sur un environnement (Sandbox de développement), les tester sur un autre environnement (sandbox de recette ou UAT) et finalement l’utiliser sur l’environnement de production.
L’objectif de cet article est de vous présenter la façon dont ces environnements peuvent communiquer en termes de déploiement. Comment les développements ou mises à jour qui ont été réalisées en sandbox de développement peuvent être basculés ou plutôt déployées vers l’environnement de recette, puis vers la production ?
Plusieurs méthodes de déploiement existent sur Salesforce et je vais vous les présenter.
Quelles sont les différentes méthodes de déploiement sur Salesforce ?
Réplication des modifications
Tout d’abord, la première méthode est tout simplement de dupliquer manuellement les modifications dans un environnement. L’idée reçue est qu’il s’agit plutôt d’une mauvaise pratique, je suis entièrement d’accord avec cela !
En effet, pour les raisons mentionnées plus haut, il est préférable d’éviter à tout prix de faire des réplications manuelles.
En revanche, dans le contexte de Salesforce, il y a certaines configurations qui doivent se faire manuellement (je ne parle pas de profils qui peuvent être déployés). Nous retrouverons l’activation de features tel que Chatter, par exemple.
Il y a aussi une liste de métadata qui n’est pas supportée par la metadata API Salesforce. Vous trouverez la liste ici : https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_unsupported_types.htm
Change Set
En second lieu, il y a les fameux ensembles de modifications entrants et sortants de Salesforce. Ces derniers existent depuis 2013. Ils ont été conçus dans l’idée de pouvoir tout déployer en « point and click », c’est-à-dire, sans ligne de commande. Les administrateurs Salesforce de tous niveaux peuvent l’utiliser pour faire des déploiements entre environnements connectés.
Les Change Set sont disponibles à partir de la configuration et il suffit d’aller dans « Ensemble de modification sortant » pour réaliser un déploiement (si vous êtes administrateur de votre org Salesforce naturellement). Il vous suffit de choisir les composants à déployer et à attendre qu’ils apparaissent dans votre environnement cible pour le déployer.
ANT Migration Tool
Ensuite, il y a la solution Ant. Cet outil utilise la metadata API pour récupérer des composants développés en local en format xml. Une fois les fichiers téléchargés, ces derniers pourront par la suite être utilisés pour être modifiés et/ou déployés sur l’environnement cible de notre choix. Ainsi le déploiement par ANT nécessite l’installation de JAVA et la possibilité de faire des lignes de commandes ANT.
Managed et unmanaged Packages
Il y a également les managed et unmanaged packages qui peuvent être adaptés quand vous avez un socle à déployer sur plusieurs environnements. C’est un ensemble de composants qui peut être installé sur un ou plusieurs environnements différents. Ensuite, vous pouvez faire des installations de mise à jour.
Les unmanaged packages permettent aux développeurs de voir et de modifier vos composants alors que ce n’est pas le cas des managed packages; qui ne permettent même pas de voir les composants.
Vous pouvez voir l’article de Fabien sur l’installation des managed packages de 2e génération.
SFDX + VSCode
L’utilisation de SFDX une solution qui est principalement adaptée si vous avez une équipe de développeurs. Lucile a écrit un super article qui vous permet de découvrir les bases de SFDX : https://blog.texei.com/my-sfdx-stories-1-mes-premiers-pas-avec-sfdx-32f82e2ee44e
L’équipe de Texeï a développé un plugin pour faciliter les déploiements que vous trouverez ici : https://github.com/texei/texei-sfdx-plugin
Ce mode de déploiement nécessite une équipe ou un accompagnement d’une personne qui connaît le fonctionnement de SFDX et de Git. Il y a une phase de montée en compétences pour les membres de l’équipe qui ne maîtrise pas (c’est généralement le cas). Une fois que cette connaissance est acquise, l’équipe est en capacité de déployer beaucoup plus rapidement qu’en passant par les Change Set et ce de manière beaucoup plus sécurisée.
DevOps Center
En 2020, Salesforce a annoncé le lancement de DevOps Center (voir cet article pour plus d’informations). Il sera enfin disponible en 2022. D’ailleurs, nous proposerons bientôt un article pour vous faire un retour de nos premiers tests de cet outil.
DevOps Center devrait être un outil permettant les déploiements avec un contrôle de versions. Cela manque effectivement aux Change Set. Tout comme pour ces derniers, la solution a été conçue pour être accessible à des fonctionnels, sans utilisateur de code, en privilégiant la facilité d’utilisation pour les déploiements. Il ne sera plus nécessaire de mettre des lignes de commande dans SFDX ou sur ANT. En plus, on pourra se connecter à un Git ! DevOps center devrait ainsi nous donner une vue sur le repository Git et être à la croisée des chemins entre SFDX et les Change Set.
Je n’en dirai pas plus dans cet article et je vous donne rendez-vous très prochainement dans mon prochain article dédié au sujet ! 😉
Les outils tiers pour faciliter le déploiement sur Salesforce
Copado, Autorabit, Gearset, Blue Canvas, Flossum et tant d’autres ont vu le manque qu’il y avait pour améliorer le système de déploiement dans les projets Salesforce. Même si certains d’entre eux sont disponibles avec une version gratuite, les outils tiers sont des solutions pour lesquelles il est nécessaire de prévoir un budget additionnel à vos licences Salesforce. En revanche, cela peut faciliter la vie des équipes Salesforce et sécuriser les déploiements, donc l’investissement peut être complètement justifié.
Dans la suite de cet article, je vous propose de faire une comparaison de chaque méthode sur certains critères qui me paraissent importants. Dans le cas présent, il s’agit de retours d’expérience dans le cadre des projets que j’ai menés. En effet, j’ai eu l’occasion de tester un certain nombre d’outils de déploiement et je commence à voir le fonctionnement des uns et des autres selon les situations. Dans tous les cas, à chaque fois que j’ai pu utiliser l’un de ces outils, cela m’a été très bénéfique dans la gestion du processus de déploiement.
Comment choisir votre méthode de déploiement sur Salesforce ?
Au regard de toutes ces options, vous pouvez vous demander comment choisir la meilleure méthode de déploiement selon votre situation et vos besoins. Comme nous l’avons vu, de nombreux paramètres entrent en jeu. Cependant, j’ai tenté de vous donner dans le tableau ci-dessous quelques critères qui me semblent importants à prendre. J’espère que cela pourra vous orienter et vous aider à faire votre choix.
| Change Set | ANT Migration Tool | Managed/ Unmanged packages | Outil tiers | SFDX | DevOps
Center |
|
| Connexion à Git | Non | Nécessite une commande et une configuration | Non | Oui | Nécessite une commande et une configuration | Oui |
| Niveau de compétence nécessaire pour l’utilisation | Bas | Elevé | Moyen | Bas | Elevé | Bas |
| Coût | Gratuit | Gratuit | Gratuit | Certaines versions gratuites mais payantes pour la plupart | Gratuit | Gratuit pour la version de base et payant après |
| Intégration de tests automatiques | Non | Nécessite un développement | Non | Oui pour la plupart des versions | Nécessite un développement | Non connu pour le moment |
| Déploiement sur AppExchange | Non | Non | Oui pour les managed packages | Non | Non | Non |
| Interface utilisateur | Point and click | Ligne de commande | Point and click | Point and click | Ligne de commande | Point and click |
Pour conclure, avant de vous lancer dans le choix d’une solution, je vous invite à réaliser une étude plus approfondie et à rencontrer les éditeurs afin d’avoir une vision plus complète et détaillée de leurs solutions.
Ainsi cet article se termine, merci de m’avoir lu et je vous retrouve très bientôt à propos du DevOps Center notamment 😁
Ressource complémentaire :
- Article Salesforce sur les organisations sandbox : https://help.salesforce.com/s/articleView?id=sf.deploy_sandboxes_parent.htm&type=5
