Comment utiliser Cloud Deploy pour déployer les évolutions ?

La bonne pratique est de développer les nouvelles fonctionnalités sur un environnement de test appelé Sandbox.
Salesforce impose (pour sécuriser les applications) de réaliser les développements Apex sur la Sandbox.
Il est vivement recommandé de réaliser toutes les évolutions sur la sandbox (paramétrages et développements), de les tester, de vérifier qu'elles correspondent au besoin puis de les migrer sur la Production.

Il existe plusieurs outils pour faire migrer la configuration : les packages Appexchanges "privés" (ancêtres du cloud deploy), Eclipse, Ant et les packages "Cloud Deploy". C'est cette méthode qui est selon moi la meilleure et de loin, c'est celle que je présente donc dans cet article au travers d'un exemple : l'ajout de champ sur compte.

Toutes les manipulations sont effectuées depuis le menu : Configuration | Déployer

1. Autoriser les modifications entrantes
Depuis la production, aller dans Connexions de déploiement cliquer sur le Modifier à gauche de la Sandbox test et cliquer sur "Autoriser les modifications entrantes" (la seule case non grisée en fait) et enregistrer.

2. Créer le package
Depuis la Sandbox, aller dans le sous-menu Ensemble de modification sortant et cliquer sur Nouveau pour créer le package  :

Dans les Composants de l'ensemble de modification, cliquer sur Ajouter puis sélectionner le type de composant : Champ personnalisé, naviguer dans la liste des champs grâce aux lettres puis sélectionner le champ à migrer et cliquer sur Ajouter à l'ensemble de modifications.

Répéter la même opération pour ajouter la ou les présentation(s) de page de compte sur laquelle apparaît le champ. (Si on n'ajoute pas la présentation de page le champ n'apparaît pas et il faut le rajouter manuellement.)

Cliquer ensuite sur Ajouter des profils dans la liste associée Paramètres de profil pour des composants inclus et sélectionner tous les profils :

L'ajout de profils permet de migrer les permissions associées aux composants du package et ces permissions là uniquement et de les ajouter aux profils existants sans modifier les autres éléments. Le matching se fait sur le nom du profil. Dans cette exemple, nous ajoutons les droits au niveau du champs aux profils existants (les Field Level Security). Sans cette étape, le champ est créé non visible pour tous les profils.


3. Charger le package
Cliquer sur Charger et sélectionner l'environnement Production.

3. Déployer le package
En production, aller dans Ensemble de modifications entrant et cliquer sur le package (il peut mettre plusieurs minutes à être disponible). Cliquer sur Déployer. Une fenêtre "Déploiement en cours" s'affiche, puis le résultat du déploiement :



Le déploiement peut être assez long surtout si vous avez du code Apex sur votre environnement, car tous les tests unitaires sont exécutés lors du déploiement.

Quels peuvent-être les causes d'échecs de déploiement ?

• Echec des tests unitaires
• Référence à un composant absent (par exemple un champ de la présentation de page n'est ni dans l'instance cible ni dans le package)

Il est possible de Valider le package pour s'assurer qu'il est correct avant le déploiement proprement dit.

En cas d'échec, le package d'origine doit être cloné c'est pourquoi il est utile d'ajouter un versionning dans le nom du package.

Que peut-on migrer avec les packages Cloud-Deploy ?

Pratiquement tout, Cloud deploy gère l'ajout et la modification de (liste non exhaustive) :
- Champs, présentation de page, règles de validation
- Règles et actions de workflow
- Documents
- la traduction (appliquée uniquement aux éléments du package)
- les rapports, types de rapports et les tableaux de bords
- les développements (Visualforce, Apex)
- les vues
- les composants et présentations de page d'accueil

Quelles sont les limitations des packages Cloud Deploy ?

Pour la version Spring 12, cela est je pense amené à évoluer car depuis la sortie de Cloud Deploy (en version Beta en Summer 10 si je me souviens bien), la liste des éléments packageables s'est considérablement aggrandie :

- les suppressions (de champs, de règles de validation, de Workflows, de classes, etc etc) : le cloud deploy fonctionne en ajout/modification uniquement

-> Pour les suppressions, je vous recommande de désactiver (ou cacher) via le Cloud Deploy puis de faire une opération de suppression post-déploiement une fois que l'on est sûr que le déploiement est un succès. Cette technique permet de faciliter un éventuel retour arrière.

- les permissions de profil : concernant les profils, seuls les éléments liés aux composants du package sont migrés.
- les valeurs de liste de sélection de champs standards puisque l'on ne peut migrer que les champs personnalisés
- les renommages de champs ou onglets standards
- les workflows d'approbation (hélas !)
- les suppressions de valeurs dans les champs de type picklist
- les filtrages des valeurs de picklist par type d'enregistrement (même lorsque l'on ajoute le type d'enregistrement dans le package). Sur les objets ayant des types d'enregistrement il sera nécessaire d'aller associer manuellement les valeurs par type d'enregistrement


Peut-on désinstaller un package installé par Cloud Deploy ?
La réponse est Non, c'est pourquoi en cas de déploiement impactant il est conseillé de lister précisément tous les composants du déploiement pour être capable de revenir en arrière manuellement.

Avant de déployer, lancer une copie de l'environnement sur une autre sandbox si vous en avez une pour garder une trace de la configuration avant déploiement ou a défaut faire une sauvegarde des Meta-données sur Eclipse par exemple.

Il peut être utile d'avoir une procédure écrite de retour arrière.

Il est aussi recommandé d'écrire une procédure de déploiement contenant l'ordre des actions (déploiement, actions manuelles à la marge, chargements de données)