Salesforce - Comment déployer des environnements (Sandbox, Live, etc.)
Nous étudions la possibilité de mettre en place un processus de déploiement approprié.
D'après ce que j'ai lu, il semble y avoir 4 méthodes pour le faire.
- Copier-coller - Nous ne voulons pas faire cela
- Utilisation du mécanisme "Package" intégré à l'interface Web de Salesforce
- Eclipse Force IDE "Option" Déployer sur le serveur "
- Ant Script (je n'ai pas encore essayé celui-ci)
Est-ce que quelqu'un a des conseils sur la limitation des différentes méthodes?.
Pouvez-vous tout inclure dans un package d'interface Web?
Nous cherchons à déployer les éléments suivants:
Classes Apex
Déclencheurs Apex
Flux de travail
Modèles de courrier électronique
Modèles MailMerge - Impossible de trouver ceux-ci dans Eclipse
Les champs personnalisés
Mise en page
RecordTypes (n'arrive pas à trouver ces informations dans Website ou Eclipse)
Articles PickList?
SControls
Je recommande le Force.com Migration Tool .
Pour référence:
L'outil de migration vous permet d'utiliser des cibles ant pour déplacer vos métadonnées entre les organisations salesforce.com.
Je peux parler de cette expérience douloureuse récente.
Packaging: il s'agit d'une méthode très ancienne, antérieure à l'API de métadonnées sur laquelle s'appuient à la fois Ant et Eclipse. D'après notre expérience, le seul avantage de l'emballage est de définir votre projet. Si vous utilisez Eclipse (ce que nous faisons, et je le recommande), vous pouvez définir votre projet comme étant basé sur un package particulier. Tant que vous pensez ajouter de nouveaux composants à votre package, votre projet est suspendu.
Une chose qui nous a déconcertés pendant un moment, d'ailleurs, sont les nombreuses utilisations de package. Nous avons noté ce qui suit:
Paquets installés: ceux-ci existent en versions gérées et non gérées et constituent, pour reprendre les termes d'un récent article sur les forums SFDC, un outil permettant aux éditeurs de logiciels de déployer leurs contenus dans diverses organisations inconnues "là-bas". Les packages gérés et non gérés ont des limitations qui les rendent inappropriés et inutiles pour le déploiement du développement à la production au sein d'une organisation, ou dans tous les cas où vous effectuez un développement personnalisé et que vous n'avez pas l'intention de distribuer du code sur une base anonyme étendue.
Packages non installés: c'est ce que vous voyez lorsque vous cliquez sur "Packages" dans l'interface utilisateur Web. Ceux-ci, que nous appelons parfois "packages de développement", ne semblent être qu'un moyen pratique de conserver une définition de projet ensemble.
Quoi qu'il en soit, la conclusion à laquelle je parviens est que notre équipe (développement personnalisé, pas un ISV) n'a besoin de packages sous aucune forme.
Les autres formes de déploiement, à la fois Eclipse et Ant, reposent sur l'API de métadonnées. En théorie, ils sont capables d'exactement les mêmes choses. En réalité, ils semblent être complémentaires. L'outil de migration Force.com, intégré à Force.com IDE pour Eclipse, facilite le déploiement (ce qui n'est pas très difficile) et vous donne un bon aperçu des tâches qu'il compte déployer. D'autre part, nous avons vu Ant faire certaines choses que IDE ne pouvait pas. Donc, il vaut probablement la peine d'apprendre les deux.
Le processus que nous préconisons consiste à conserver tous nos projets dans SVN et à utiliser la structure SVN comme définition du projet (Eclipse travaillera avec cela et le respectera). Et nous utilisons Eclipse et parfois Ant pour la migration. Aucun besoin apparent de colis n'importe où.
En passant, une dernière chose à prendre en compte: tous les composants ne peuvent pas être migrés. Certaines choses doivent être reconfigurées à la main dans l'environnement cible. Un exemple serait les workflows temporels. Les files d'attente et les groupes doivent également être créés à la main, je pense. De même, l'API de métadonnées ne peut pas traiter directement les suppressions de champs. Ainsi, si vous supprimez un champ dans votre source, vous devez le supprimer manuellement dans la cible. Il y a aussi d'autres cas.
J'espère que c'est utile -
- Steve Lane
À partir du printemps 2009, les modèles de publipostage ne sont pas pris en charge dans les métadonnées, contrairement aux types d'enregistrement. Vous trouverez des types d'enregistrement sous forme d'élément XML dans le fichier pour l'objet auquel ils appartiennent. Tout le reste de votre liste est pris en charge à une petite exception près. Les valeurs de liste de sélection pour les champs standard ne peuvent pas être modifiées dans Spring '09. Restez à l'affût des dernières nouvelles sur les annonces de l'été 2009.
Mise à jour: les listes de sélection standard sur les objets standard sont désormais exposées aux métadonnées (à partir de l'API v16): http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_picklist.htm
Sinon, la réponse de Steve Lane est assez précise. L'avantage d'utiliser des packages non gérés (ce que Steve appelle des packages non installés) est que lorsque vous ajoutez des métadonnées à un package, les métadonnées dont il dépend seront automatiquement ajoutées. Il est donc plus facile de récupérer un ensemble complet de métadonnées contenant toutes ses dépendances. Si vous déplacez à plusieurs reprises des métadonnées d'une organisation (bac à sable) à une autre (production), l'approche de Steve est probablement la meilleure voie à suivre et certainement la plus courante aujourd'hui. J'utilise fréquemment des packages de "développeur" non gérés pour déplacer quelque chose que j'ai développé dans une organisation vers une autre organisation sans rapport. Pour ce qui me concerne, j'aime bien définir le paquet dans l'org par opposition à un projet/SVN Eclipse. Mais cela n’a probablement aucun sens si vous effectuez un développement d’équipe dans de nombreux organismes de développement/sandbox et utilisez déjà SVN.
Jesper
Une autre option consiste à utiliser Modifier les ensembles si vous souhaitez déplacer les métadonnées d'un bac à sable vers la production.
Il existe actuellement quelques limitations sur la façon dont les ensembles de modifications peuvent être utilisés:
L'envoi d'un jeu de modifications entre deux organisations nécessite un déploiement lien. Actuellement, les ensembles de modifications ne peuvent être envoyés qu'entre organisations affiliées à une organisation de production, par exemple Par exemple, une organisation de production et un bac à sable, ou deux bacs à sable créé à partir de la même organisation.
Je me bats toujours avec ça moi-même. Ni le IDE de l'outil de migration n'a résolu les problèmes principaux que je rencontre, qui sont les suivants:
Les packages installés ne peuvent pas être déployés dans une organisation de développeur. Vous devez les installer manuellement un à un dans l’Organe de développement.
Si un package ne peut pas être installé dans l'organisation (par exemple, il nécessite un mot de passe, tel que Marketo Sales Insight , ou parce qu'il est obsolète, tel que Salesforce for Google Adwords ) et notre application a des dépendances .__ dessus (comme des références à des champs d'objets appartenant au package ), nous ne pourrons alors pas déployer l'application.
Solution de contournement: si un package Ne peut pas être installé manuellement dans une organisation DEv, chaque développeur Aura besoin de son propre Sandbox de développeur. Des sandbox de développement supplémentaires Peuvent être commandés auprès de Salesforce. _ {(Le client doit être prêt à payer pour eux, cependant ...)}
Lorsque le sandbox est actualisé depuis la production et que nous actualisons notre projet Local (qui est connecté à SVN) à partir du serveur, tous les fichiers/.__ supplémentaires qui étaient dans l'ancien sandbox mais ne le sont pas la production va être transférée dans le nouveau bac à sable.
Solution de contournement: toutes les modifications apportées en production doivent être répliquées dans le bac à sable et les organisations Developer. (C'est un peu pénible, mais ok ...)
De la docs:
Un package doit être géré pour qu'il soit publié sur AppExchange et qu'il puisse prendre en charge les mises à niveau . Une organisation peut créer un seul package géré pouvant être téléchargé et installé par de nombreuses organisations différentes. Ils diffèrent des packages non gérés en ce que certains composants sont verrouillés, ce qui permet une mise à niveau ultérieure du package géré. Les packages non gérés n'incluent pas de composants verrouillés et ne peuvent pas être mis à niveau. En outre, les packages gérés par masquent certains composants (tels que Apex) sur les organisations abonnées, afin de protéger la propriété intellectuelle du développeur.
L’avantage du progiciel géré est qu’il vous permet de créer et de distribuer facilement des éléments dans plusieurs organisations SFDC.