Salesforce - comment se déployer entre environnements (bac à sable, Live, etc.))

je peux parler de cette récente expérience douloureuse.

Packaging: il s'agit d'une méthode très ancienne qui précède l'API métadonnées sur laquelle Ant et Eclipse s'appuient. Selon notre expérience, le seul avantage de packaging 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. Aussi longtemps que vous vous rappelez d'ajouter de nouveaux composants à votre paquet, votre projet tient bon

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

paquets installés: ceux-ci viennent dans les saveurs gérées et non gérées et sont vraiment, selon les mots d'un post récent sur les cartes de la SFDC, pour ISVs de déployer leurs trucs dans divers orgs inconnus "là-bas". Les progiciels gérés et non gérés ont des limites 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 faites du développement personnalisé et n'avez pas l'intention de 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 commode pour garder une définition de projet ensemble.

quoi qu'il en soit, la conclusion que j'en Tire est que notre équipe (custom development, pas un ISV) n'a pas besoin de paquets toute forme.

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

le processus vers lequel nous nous orientons est de conserver tous nos projets en SVN, et d'utiliser la structure SVN comme définition du projet (Eclipse fonctionnera avec cela et le respectera). Et nous utilisons Eclipse et parfois Ant pour la migration. Aucun besoin apparent de paquets nulle part.

soit dit en passant, une chose de plus dont il faut être conscient -- tous les composants ne sont pas migrables. Certaines choses doivent être reconfigurées par la main dans l'environnement cible. Un exemple serait en fonction du temps de flux de travail. Les files d'attente et les groupes doivent aussi être créés, je pense. De même, l'API métadonnées ne peut pas traiter directement les suppressions de champs.si vous avez supprimé un champ dans votre source, vous devez le supprimer à la main dans la cible. Il y a d'autres cas aussi.

j'Espère que c'est utile --

-- Steve Lane

depuis le printemps 2009, les modèles de fusion de courriels ne sont pas pris en charge dans les métadonnées, mais les types d'enregistrements le sont. Vous trouverez les types d'enregistrement comme élément XML dans le fichier pour l'objet auquel ils appartiennent. Tout le reste de votre liste est supporté avec une petite exception. Les valeurs des listes de sélection pour les champs standards ne peuvent pas être modifiées au printemps 2009. Restez à l'affût des nouvelles sur les annonces de l'été 2009.

mise à jour: les listes de sélection Standard sur les objets standard sont maintenant 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 paquets non gérés (ce que Steve appelle des paquets non installés) est que lorsque vous ajoutez des métadonnées à un paquet, les métadonnées dont il dépend seront automatiquement ajoutées. Il est donc plus facile à saisir un ensemble complet de métadonnées contenant toutes ses dépendances. Si vous déplacez de façon répétée les métadonnées de D'un org (sandbox) à un autre (production), L'approche de Steve est probablement la meilleure façon de faire et certainement la plus courante aujourd'hui. J'utilise souvent des paquets de "développeur" non gérés pour déplacer quelque chose que j'ai développé dans une organisation à une autre. Pour mon but, j'aime avoir le paquet défini dans l'organisation par opposition à un projet Eclipse / SVN. Mais cela n'a probablement pas de sens si vous faites le développement d'équipe à travers de nombreux orgs de dev/sandbox et utilisez déjà SVN.

Jesper

une autre option est d'utiliser Change Sets si vous voulez déplacer des métadonnées d'un bac à sable à la production.

il y a actuellement quelques restrictions sur la façon dont les ensembles de changement peuvent être utilisés:

envoyer un ensemble de changement entre deux organisations nécessite un déploiement connexion. Actuellement, les jeux de changement ne peuvent être envoyés qu'entre les organisations affiliées à une organisation de production, pour exemple, un organisation de la production et un bac à sable, ou deux bac à sable créé à partir de la même organisation.

à Partir de la documentation:

un paquet doit être géré pour qu'il soit publié publiquement sur AppExchange, et pour qu'il supporte les mises à jour . Une organisation peut créer un paquet géré unique 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 au paquet géré d'être mis à niveau plus tard. Les colis non gérés ne comprennent pas de composants verrouillés et ne peuvent pas être de mise à niveau. De plus, gère les paquets obscurcissent certains composants (comme Apex) sur les organisations abonnées, afin de protéger la propriété intellectuelle du développeur.

avantage pour le paquet géré serait qu'il vous permet de facilement modifier et distribuer des choses à travers plusieurs organisations de la SFDC.

je me bats encore avec ça moi-même. Ni L'IDE de L'outil de Migration n'ont résolu les principaux problèmes auxquels je fais face, qui sont les suivants:

1. les paquets installés ne peuvent pas être déployés dans un Developer Org . Vous devez installez-les manuellement un par un dans la Dev Org.

   si un colis ne peut pas être installé dans l'organisation (par exemple parce qu'il nécessite un mot de passe, comme Marketo Sales Insight , ou parce qu'il a été déprécié, comme Salesforce pour Google Adwords ) et notre application a des dépendances (comme les références à des champs dans les objets qui appartiennent à la package) alors nous ne serions pas en mesure de déployer l'application.

   contournement : si a le paquet ne peut pas être installé manuellement dans un Dev Org chaque développeur aura besoin de son propre développeur bac à sable. Bacs À Sable Pour Développeur Supplémentaires peut être commandé à partir de Salesforce. (le client doit être prêt à payer pour eux, cependant...)

2. quand le bac à sable est rafraîchi de la production et nous rafraîchir notre projet local (qui est connecté à SVN) à partir du serveur tous les fichiers/code supplémentaires qui étaient dans le vieux bac à sable mais il n'est pas dans la production va être déplacé dans le nouveau bac à sable.

   contournement : tout les modifications apportées à la production doivent être reproduites dans le bac à sable et Orgs Développeur. (sorte d'une douleur, mais ok...)

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