[My SFDX Stories #1] Mes premiers pas avec SFDX

Lorsque j’ai pris mon poste chez Texeï, j’ai été affectée à une mise en place de Salesforce.

Ce que j’aime avec cet outil c’est l’éternel renouveau, il a toujours des choses à apprendre.

Et le hasard a bien fait les choses puisqu’un nouveau challenge s’est présenté à moi. Il fallait que j’utilise SFDX pour m’intégrer dans un projet en développement continu.

Je n’avais jamais entendu ce terme mais je me suis dit “Pourquoi pas !”.

Pour commencer qu’est-ce que SFDX ?

Plus exactement, il s’agit de SFDX CLI, Salesforce Developer Experience Command Line Interface, un outil en ligne de commande permettant de faire des développements Salesforce Platform.

En tant qu’AppBuilder, je me suis un peu inquiétée en voyant les mots “ligne de commande”.

Je ne suis pas du tout développeuse et mes dernières expériences en ligne de commande dataient de l’école et je ne me souvenais plus comment me déplacer dans une arborescence de fichiers.

Travailler en ligne de commande ok, mais comment ? Comment cela s’articule avec Salesforce?

Réponse : Les Scratch Orgs

Une Scratch Org est un environnement Salesforce “jetable” qui peut prendre toutes les caractéristiques possibles d’une organisation Salesforce.

J’ai besoin d’une organisation Sales Cloud avec Person Account ? Pas de soucis. Service Cloud avec Email-to-Case? Aucun problème. Et tout ça, sans passer par le Service Client Salesforce.

Comment SFDX fonctionne ?

Grâce à VSCode, on se connecte à un environnement de production.

VSCode est un éditeur de code. Pour en savoir plus, il existe un très bon trailhead.

Puis on va pouvoir créer et ouvrir une Scratch Org via des lignes de commande et paramétrer les fonctionnalités “normalement” dessus.

Une fois la fonctionnalité mise en place, on récupère les fichiers de metadata qui constituent un environnement Salesforce. Grâce à VSCode cette opération est très simple.

Les metadatas sont des fichiers XML qui représentent les objets Salesforce. Pour en savoir plus, il existe aussi un trailhead sur le sujet.

On envoie ensuite les fichiers sur un outil de versionning de code, ici gitlab, qui déploie ces fichiers sur une sandbox.

Les nouvelles fonctionnalités sont alors testées sur la sandbox. Si les tests sont concluants, les fonctionnalités sont alors déployées en production.

Ce que je retiens de cette première expérience

Après cette première utilisation de SFDX, je peux dire que je ne me vois plus travailler autrement.

Une fois les appréhensions passées, j’ai trouvé une méthode et une rigueur qui manquaient peut-être lors de mes précédents paramétrages.

Les moins :

• Nouvelle méthodologie à appréhender.

Les plus :

• Facilitation de la mise en production.
• Plus besoin de passer par le service client Salesforce pour activer une fonctionnalité en sandbox afin de faire une démonstration.

Convaincue par mon expérience SFDX, je continuerai à écrire quelques billets concernant les problèmes que je rencontrerai et leurs solutions de mon point de vue d’AppBuilder.

Et si vous voulez démarrer avec SFDX, nous avons écrit un livre blanc gratuit pour vous aider ! 

Sources :

• https://medium.com/@JeffLombardJr/what-is-the-sfdx-cli-4115248541e3