Le problème

J'ai toujours souhaité que Salesforce les déploiements étaient plus faciles. En tant que développeur, j'ai vu de nombreuses journées perdues à cause de ce processus de déploiement fastidieux et sujet aux erreurs.

Un déploiement Salesforce typique ressemble à ceci :

1. Modifier du code.
2. Enregistrez les fichiers que vous avez supprimés, ajoutés et modifiés.
3. Connectez-vous à un sandbox où réside le code.
4. Créer un ensemble de modifications.
5. Sélectionnez manuellement chaque composant que vous souhaitez déployer.
6. Sélectionnez la cible sur laquelle vous souhaitez déployer le jeu de modifications.
7. Connectez-vous à l’organisation cible où vous avez envoyé votre ensemble de modifications.
8. Trouvez votre ensemble de modifications.
9. Appuyez sur déployer.

Comme vous pouvez le constater, la liste est assez longue. Chaque étape doit être effectuée manuellement et l'ensemble du processus est sujet à des erreurs. Si vous souhaitez effectuer un déploiement dans plusieurs environnements, vous devez répéter l'intégralité de ce processus pour chacun d'eux.

J'ai rencontré de nombreux problèmes avec ce processus, notamment :

1. Ensembles de modifications avec des composants manquants. La nécessité de suivre manuellement chaque fichier modifié peut entraîner des ensembles de modifications incomplets qui doivent être reconstruits et réappliqués à l'organisation cible.
2. L'organisation cible doit disposer des autorisations et de la configuration appropriées pour accepter les ensembles de modifications.
3. Étant donné que le code est présent, testé et « déployé » dans Salesforce, il peut exister en dehors du contrôle de version. Il est ainsi très facile d'écraser le travail d'autres personnes si vous travaillez à partir d'un sandbox obsolète.
4. Les ensembles de modifications prennent du temps à se propager aux organisations cibles, vous finissez donc par passer beaucoup de temps à attendre que Salesforce fasse son travail.

La solution

Je voulais utiliser le même système de déploiement que nous utilisons pour tout le reste chez PagerDuty. Nous utilisons un système de déploiement interne nommé Igor contrôlé via notre Lita bot appelé OfficierURL (URL en abrégé). L'URL nous permet de déployer notre code avec une seule commande dans Slack.

 !déployer Salesforce<branch:default is master> à<environment> 

Ainsi, par exemple, pour déployer la branche principale de notre code Salesforce en production, nous taperions :

 !déployer Salesforce en production 

Le bot nous indiquera ensuite s'il a réussi ou échoué. Il nous relie également aux journaux de déploiement dans Igor.

Voici une capture d'écran d'un déploiement Salesforce réel que j'ai effectué récemment :

C'est vraiment aussi simple que ça.

La mise en place

À un niveau élevé, notre duo bot / déployeur fait ce qui suit :

1. Consultez le référentiel GitHub du projet.
2. Passe à la branche spécifiée.
3. Exécute un script de déploiement dans le référentiel extrait, en lui fournissant la cible de déploiement.
4. Nous informe du succès ou de l'échec du déploiement en fonction du code de sortie du script.

L'outil qui a permis ce flux de travail est https://github.com/neowit/tooling-force.com .

L'un des principaux avantages de cet outil est qu'il permet des déploiements qui suppriment des composants de Salesforce qui n'existent plus dans le répertoire de travail. En effet, il permet à la copie du projet de Salesforce de correspondre autant que possible à votre répertoire de travail. La plupart des autres outils déploient uniquement les fichiers du répertoire de travail ; ils ne suppriment pas les composants de Salesforce qui n'existent plus localement. Cela peut entraîner le maintien du code actif dans Salesforce alors qu'il aurait dû être entièrement supprimé.

Voici la commande qui s'exécute lorsque vous effectuez un déploiement via le chat :

 java -jar path.to.jar --action=deployAllDestructive --config=path.to.properties --projectPath=. --responseFilePath=/dev/stdout --maxPollRequests=200 --specificTypes=./src/package.xml --typesFileFormat=packageXml | tee déployer.stdout grep 'RESULT=SUCCESS' déployer.stdout 

Vous pouvez télécharger un fichier jar de l'outil à l'adresse https://github.com/neowit/tooling-force.com/releases .

Notez que path.to.properties possède une variable qui représente l'environnement dans lequel déployer afin que nous puissions déployer dans plusieurs environnements.

Le fichier de propriétés :

 sf.username=nom d'utilisateur sf.password=mot de passe sf.serverurl=https://login.salesforce.com ou https://test.salesforce.com 

Le fichier package.xml est enregistré dans git et spécifie les composants à déployer. J'utilise :

 <?xml version="1.0" encoding="UTF-8"?><Package xmlns="http://soap.sforce.com/2006/04/metadata"><types><members> *</members><name> Classe Apex</name></types><types><members> *</members><name> Composant Apex</name></types><types><members> *</members><name> Page Apex</name></types><types><members> *</members><name> Déclencheur Apex</name></types><types><members> *</members><name> Ressource statique</name></types><version> 34.0</version></Package> 

Crédits

Cela aurait été plus difficile à mettre en œuvre sans notre formidable équipe DevTools. Ils gèrent le bot qui fournit des fonctionnalités communes telles que la gestion du checkout git, les notifications d'état et la journalisation lors de l'exécution d'un script de déploiement.

Merci également à Andrey Gavrikov ( neowit sur GitHub ) pour fournir l'application de ligne de commande tooling-force.com qui permet des déploiements Salesforce faciles à partir d'un dossier.