Salesforce - Comment déployer entre les environnements (Sandbox, en direct, etc.)

Question

Nous sommes à la recherche dans la mise en place d'un processus de déploiement approprié.

D'après ce que j'ai lu semble qu'il y ait 4 méthodes de le faire.

1. Copier et Coller - Nous ne voulons pas faire
2. Utilisation du mécanisme "Package" intégré dans l'interface Web Salesforce
3. Eclipse IDE force "Déploiement de serveur option"
4. Ant Script (ont pas essayé celui-ci encore)

Quelqu'un at-il des conseils sur la limitation des différentes méthodes.

Pouvez-vous tout inclure dans un paquet d'interface Web?

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

• Classes Apex

• Triggers Apex

• WorkFlows

• Modèles de courrier électronique

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

• Champs personnalisés

• Mise en page

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

• Les produits de PickList?

• SControls

Answer 1

Je recommande Force.com Migration outil.

Pour référence:

• Force.com Migration Tool Documentation
• Guide outil de migration

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 par expérience douloureuse récente.

Conditionnement: c'est une méthode très ancienne qui est antérieure à l'API de métadonnées sur lequel les deux Ant et Eclipse comptent. Dans notre expérience, seul avantage de l'emballage est dans la définition de votre projet. Si vous utilisez Eclipse (ce que nous faisons, et je recommande), vous pouvez définir votre projet comme étant basé sur un ensemble particulier. Tant que vous vous souvenez d'ajouter de nouveaux composants à votre forfait, votre projet se tient

Une chose qui nous déconcerté pendant un certain temps, d'ailleurs, les nombreuses utilisations du paquet. Nous avons noté ce qui suit:

Les paquetages installés: ceux-ci viennent en saveurs gérés et non gérés et sont vraiment, dans les mots d'un récent sur les planches SFDC, pour les éditeurs de logiciels pour déployer leurs trucs dans divers orgs inconnus « là-bas ». Les deux gérés et non gérés paquets ont des limites qui les rendent impropres et non nécessaire pour le déploiement du développement à la production au sein d'une org, ou dans tous les cas où vous faites un développement personnalisé et ne pas l'intention de distribuer le code à une base anonyme.

Les emballages non installés: c'est ce que vous voyez lorsque vous cliquez sur « Packages » dans l'interface utilisateur Web. Ceux-ci, que l'on appelle parfois des « paquets de développement », semble être juste un moyen pratique de garder une définition de projet ensemble.

Quoi qu'il en soit, la conclusion que je viens vers est que notre équipe (développement personnalisé, pas un ISV) n'a pas besoin de paquets sous aucune forme.

Les autres formes de déploiement, à la fois Eclipse et Ant, comptent sur l'API des 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é dans l'IDE Force.com pour Eclipse, rend le déploiement aussi facile que possible (ce qui est peu) et vous donne une belle apparence à ce qu'il a l'intention de déployer. D'autre part, nous avons vu Ant faire des choses l'IDE ne pouvait pas. Il est donc sans doute utile d'apprendre les deux.

Le processus que nous sommes en se penchant vers est de garder tous nos projets dans SVN, et utiliser la structure SVN comme la définition du projet (Eclipse fonctionnera avec cela et le respecter). Et nous utilisons Eclipse et parfois Ant pour la migration. Pas besoin apparent pour les paquets partout.

Par ailleurs, une chose à prendre en compte - tous les composants sont lixiviable. Certaines choses doivent être reconfigurés à la main dans l'environnement cible. Un exemple serait des flux de travail basés sur le temps. Les groupes doivent files d'attentes et également behand créé, je pense. De même, l'API de métadonnées ne peut pas traiter directement les suppressions sur le terrain, donc si vous avez supprimé un champ dans votre source, vous devez supprimer la main dans la cible. Il y a d'autres cas aussi.

Hope 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 les types d'enregistrement comme un élément XML dans le fichier de l'objet auquel ils appartiennent. Tout le reste sur votre liste est pris en charge avec une petite exception. valeurs pour les champs PickList standard ne peuvent pas être modifiés au printemps '09. Restez à l'écoute des nouvelles sur les annonces de fonctionnalités d'été '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 / contenu / meta_picklist.htm

Dans le cas contraire, la réponse de Steve Lane est assez précis. L'avantage d'utiliser les paquets non gérés (ce que Steve appelle les paquets non installés) est que lorsque vous ajoutez des métadonnées à un package, les métadonnées, il dépend sera automatiquement ajouté. Il est donc plus facile de prendre un ensemble complet de métadonnées contenant toutes ses dépendances. Si vous à plusieurs reprises les métadonnées se déplacent d'un org (bac à sable) à une autre (production), l'approche de Steve est probablement la meilleure façon d'aller et certainement le plus courant aujourd'hui. J'utilise souvent des paquets « développeurs » non gérés pour déplacer quelque chose que j'ai développé dans l'une à l'autre org org sans rapport. Pour mon but, je voudrais avoir le package défini dans l'org, par opposition à un projet / SVN Eclipse. Mais cela ne peut-être pas de sens si vous faites le développement de l'équipe à travers de nombreux orgs dev / bac à sable et utilisent SVN déjà.

Jesper

Answer 4

Une autre option consiste à utiliser Définit si les changements que vous souhaitez déplacer les méta-données à partir d'un bac à sable à la production.

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

  

L'envoi d'un changement situé entre deux organisations nécessite un déploiement   lien. À l'heure actuelle, les ensembles de changement ne peuvent être envoyés entre   les organisations affiliées à une organisation de production, pour   exemple, une organisation de production et un bac à sable, ou deux bacs à sable   créé à partir de la même organisation.

Answer 5

A partir de la documentation:

Un paquet doit être géré pour qu'il soit publié publiquement sur AppExchange, et à soutenir les mises à jour . Une organisation peut créer un package unique géré qui peut ê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 le package réussi à être mis à jour plus tard. emballages non gérés ne comprennent pas les composants verrouillés et ne peuvent pas être mis à niveau. En outre, packages gérés occultent certains composants (comme Apex) sur les organisations souscrivant, de manière à protéger la propriété intellectuelle du développeur.

Avantage à forfait serait géré qu'il vous permet de facilement la version et de distribuer les choses à travers plusieurs organisations SFDC.

Answer 6

Je suis toujours aux prises avec moi-même. Ni l'IDE de l'outil de migration ont résolu les principaux problèmes que je rencontre, qui sont les suivantes:

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

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

   Solution : si paquet ne peut pas être installé manuellement dans une Dev Org chaque développeur aura besoin de son propre développeur Sandbox. Sandboxes Developer supplémentaires peut être commandé à partir de Salesforce. (Le client doit être prêt à payer pour eux, mais ...)

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

   Solution : tous les modifications apportées à la production doivent être reproduites dans le bac à sable et Orgs Developer. (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. Consultez ce message: https://www.deploypkg.com/deploy-to-production/