Salesforce - Déploiement entre environnements (Sandbox, Live, etc.)

Question

Nous étudions la mise en place d'un processus de déploiement approprié. D'après ce que j'ai lu il semble y avoir 4 méthodes pour le faire.

1. Copier Coller & - Nous ne voulons pas faire
2. En utilisant l'option "Package" mécanisme intégré dans l'interface Web Salesforce
3. Eclipse IDE force "Déploiement au serveur"
4. Ant Script (N'a 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 de l'Interface Web?

Nous cherchons à déployer les éléments suivants:

• Classes Apex

• Triggers Apex

• WorkFlows

• Templates Email

• MailMerge Modèles - peut sembler ne pas trouver dans Eclipse

• champs personnalisés

• Mise en page

• RecordTypes (ne peut pas sembler trouver dans site Web ou Eclipse)

• Articles PickList?

• SControls

Answer 1

Je recommande le Force.com Migration Tool.

Pour référence:

• Force.com Migration Tool Documentation
• Migration Tool Guide

L'outil de migration vous permet d'utiliser des cibles de fourmis pour déplacer vos métadonnées entre Salesforce.com organzations.

Answer 2

Je peux parler à ce sujet d'une expérience douloureuse récente.

Conditionnement: il s'agit d'une méthode très ancienne antérieure à l'API de métadonnées sur laquelle reposent Ant et Eclipse. Selon 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 recommande), vous pouvez définir votre projet comme étant basé sur un paquet particulier.Tant que vous vous souvenez d'ajouter de nouveaux composants à votre package, votre projet se bloque

Une chose qui nous a déconcerté pendant un certain temps, btw, sont les nombreuses utilisations de package. Nous avons noté ce qui suit:

Paquets installés: ceux-ci viennent dans des saveurs gérées et non managées et sont vraiment, selon les mots d'un post récent sur les cartes SFDC, pour que les ISV déploient leurs trucs dans diverses organisations inconnues ". Les packages gérés et non gérés présentent des limitations qui les rendent inutilisables 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 n'entendez pas distribuer du code à une grande base anonyme.

Paquets non installés: c'est ce que vous voyez lorsque vous cliquez sur "Paquets" dans l'interface Web. Ceux-ci, que nous appelons parfois «paquets de développement», semblent être juste un moyen pratique de garder une définition de projet ensemble.

Quoi qu'il en soit, la conclusion que je vais tirer est que notre équipe (développement personnalisé, pas un éditeur de logiciels indépendant) n'a pas besoin de paquets sous quelque forme que ce soit.

Les autres formes de déploiement, Eclipse et Ant, reposent sur l'API de métadonnées. En théorie, ils sont capables de exactement les mêmes choses. En réalité, ils semblent être complémentaires. L'outil de migration Force.com, intégré à l'IDE Force.com pour Eclipse, rend le déploiement aussi simple que possible (ce qui n'est pas vraiment le cas) et vous donne un bon aperçu de ce qu'il a l'intention de déployer. D'un autre côté, nous avons vu Ant faire certaines choses que l'IDE ne pouvait pas faire. Donc, il vaut probablement la peine d'apprendre les deux.

Le processus sur lequel nous nous orientons est de conserver tous nos projets dans SVN, et d'utiliser la structure SVN comme définition de projet (Eclipse travaillera avec ceci et le respectera). Et nous utilisons Eclipse et parfois Ant pour la migration. Aucun besoin apparent de paquets partout. Par ailleurs, une chose de plus à savoir - tous les composants ne sont pas migrables. Certaines choses doivent être reconfigurées à la main dans l'environnement cible. Un exemple serait des flux de travail basés sur le temps. Les files d'attente et les groupes doivent également être créés, je pense. De même, l'API de métadonnées ne peut pas traiter directement les suppressions de champs, donc si vous avez supprimé un champ de votre source, vous devez le supprimer manuellement dans la cible. Il y a d'autres cas aussi.

Espoir qui est utile -

- Steve Lane

Answer 3

Au printemps '09, les modèles de publipostage ne sont pas pris en charge dans les métadonnées, mais les types d'enregistrements sont. Vous trouverez des types d'enregistrement en tant qu'élément XML dans le fichier pour l'objet auquel ils appartiennent. Tout le reste de votre liste est pris en charge avec une petite exception. Les valeurs de liste de sélection pour les champs standard ne peuvent pas être modifiées dans Spring '09. Restez à l'écoute des nouvelles sur les annonces de la fonctionnalité Summer '09.

Mise à jour: picklists standard sur les objets standards sont maintenant métadonnées exposées (en 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écis. L'avantage d'utiliser des packages non gérés (ce que Steve appelle les packages non installés) est que lorsque vous ajoutez des métadonnées à un package, les métadonnées qui en dépendent sont automatiquement ajoutées. Il est donc plus facile d'obtenir 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 (sandbox) à une autre (production), l'approche de Steve est probablement la meilleure façon de procéder et certainement la plus courante aujourd'hui. J'utilise fréquemment des paquets «développeurs» non gérés pour déplacer quelque chose que j'ai développé dans une organisation vers une autre organisation non liée. Pour mon but, j'aime que le paquet soit défini dans l'org par opposition à un projet Eclipse/SVN.Mais cela n'a probablement pas de sens si vous faites du développement d'équipe à travers de nombreuses organisations dev/sandbox et que vous utilisez déjà SVN.

Jesper

Answer 4

De la documentation:

Un paquet doit être géré pour qu'il soit publié publiquement sur AppExchange, et à soutenir 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 paquets non gérés en ce que certains composants sont verrouillés, ce qui permet de mettre à jour le paquet géré plus tard. Les packages non gérés n'incluent pas de composants verrouillés et ne peuvent pas être mis à niveau. De plus, les paquets gérés masquent certains composants (comme Apex) sur les organisations abonnées, afin de protéger la propriété intellectuelle du développeur.

Avantage au paquet géré serait qu'il vous permet de facilement la version et la distribution des choses à travers plusieurs organisations SFDC.

Answer 5

Une autre option consiste à utiliser Change Sets si vous souhaitez déplacer des métadonnées d'un sandbox vers la production.

Il y a actuellement quelques limites sur la façon dont les jeux de changement peuvent être utilisés:

Envoi d'un changement situé entre deux organisations nécessite une connexion de déploiement . Actuellement, les ensembles de modifications ne peuvent être envoyés qu'entre organisations affiliées à une organisation de production, par exemple , une organisation de production et un sandbox, ou deux sandbox créés à partir de la même organisation.

Answer 6

Je suis encore aux prises avec cela. Ni l'IDE de l'outil de migration ont résolu les principaux problèmes que je rencontre, qui sont les suivantes:

1. paquets installés ne peuvent pas être déployés à un Org Developer. Vous devez les installer manuellement un par un dans le Dev Org.

   Si un paquet ne peut pas être installé dans l'org (par exemple parce qu'il nécessite un mot de passe, comme Marketo Sales Insight, ou parce qu'il a été désapprouvée, comme Salesforce for Google Adwords) et notre application a des dépendances sur elle (comme les références aux champs dans les objets qui appartiennent au package ), nous ne serons pas en mesure de déployer l'application.

   Solution: si un paquet ne peut pas être installé manuellement dans un dEv Org chaque développeur aura besoin de son propre développeur Sandbox. Des sandbox de développeur supplémentaires peuvent être commandés auprès de Salesforce. (Le client doit être prêt à payer pour eux, bien que ...)

2. Lorsque le bac à sable est mise à jour de la production et nous rafraîchir notre projet local (qui est relié à SVN) à partir du serveur tous fichiers supplémentaires/code qui était dans l'ancien Bac à sable, mais il est pas la production va être déplacée vers la nouvelle Sandbox.

   Solution: toutes les modifications apportées dans la production doivent être répliqués dans le sandbox et les développeurs Orgs. (une sorte de douleur, mais ok ...)

Answer 7

En tout déploiement de production Salesforce, l'API de métadonnées est l'une des meilleures options pour le faire. Il existe des outils qui simplifient le travail. Découvrez ce post: https://www.deploypkg.com/deploy-to-production/