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 bac à sable 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 l’ensemble 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 le processus est sujet à des erreurs. Si vous souhaitez déployer sur plusieurs environnements, vous devrez répéter l'intégralité du processus pour chacun d'eux.

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

1. Ensembles de modifications avec 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. Comme le code est hébergé, testé et déployé dans Salesforce, il peut être hébergé hors du contrôle de version. Il est donc très facile d'écraser le travail d'autres personnes si vous travaillez à partir d'un environnement 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é par 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 si l'opération a réussi ou échoué. Il nous reliera é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 configuration

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

1. Vérifie le référentiel GitHub du projet.
2. Bascule vers 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 de la réussite 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 supprimant les composants Salesforce qui n'existent plus dans le répertoire de travail. En effet, la copie du projet Salesforce correspond 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 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 déployez 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 deploy.stdout grep 'RESULT=SUCCESS' deploy.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> ApexPage</name></types><types><members> *</members><name> Déclencheur Apex</name></types><types><members> *</members><name> StaticResource</name></types><version> 34,0</version></Package> 

Crédits

Cela aurait été plus difficile à mettre en œuvre sans notre formidable équipe DevTools. Elle gère le bot qui fournit des fonctionnalités courantes 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.