Salesforce - Wie zwischen Umgebungen Bereitstellen (Sandkästen, Leben usw.)

Question

Wir suchen in einen richtigen Bereitstellungsprozess einrichten.

Von dem, was ich habe es gelesen scheint 4 Methoden, um dies zu tun.

1. Copy & Paste - Wir wollen nicht, diese
tun
2. Mit dem „Paket“ Mechanismus in das Salesforce Webinterface gebaut
3. Eclipse-Force-IDE "Deploy to Server" Option
4. Ant Script (haben diese ein noch nicht ausprobiert)

Hat jemand Rat über die Begrenzung der verschiedenen Methoden.

Können Sie enthalten alles, was in einem Web-Interface-Paket?

Wir suchen die folgenden Elemente bereitgestellt werden:

• Apex Klassen

• Apex Trigger

• WorkFlows

• E-Mail-Vorlagen

• MailMerge Templates - kann nicht scheinen, diese in Eclipse

zu finden

• Benutzerdefinierte Felder

• Seitenlayout

• RecordTypes (kann nicht scheinen, diese in Webseiten oder Eclipse zu finden)

• Listen-Elemente?

• SControls

Answer 1

Ich empfehle die Force.com Migration Werkzeug .

Referenz:

• Force.com Migration Tool Dokumentation
• Migration Tool Guide

Die Migration Tool ermöglicht es Ihnen, ant-Ziele zu verwenden, um Ihre Metadaten zwischen salesforce.com organzations zu bewegen.

Answer 2

Ich kann dies aus dem letzten schmerzlicher Erfahrung sprechen.

Verpackung: Das ist eine sehr alte Methode, die den Metadaten-API, auf der früher sowohl Ant und Eclipse verlassen. Nach unserer Erfahrung Verpackung einziger Vorteil ist, Ihr Projekt zu definieren. Wenn Sie sich mit Eclipse (was wir tun, und ich empfehle), können Sie Ihr Projekt als bezogen auf ein bestimmtes Paket definieren. Solange Sie neue Komponenten zu Ihrem Paket hinzuzufügen, denken Sie daran, Ihr Projekt hängt zusammen

Eine Sache, die uns für eine Weile ratlos, btw, sind die vielen Verwendungen von Paket. Wir haben folgendes zu beachten:

Installierte Pakete: diese kommen in verwalteten und nicht verwalteten Aromen und sind in den Worten eines kürzlich erschienenen Beitrag über die SFDC Bretter wirklich, für ISVs ihre Sachen in verschiedene unbekannte Orgs „da draußen“ zu implementieren. Beide verwalteten und nicht verwalteten Pakete haben Einschränkungen, die sie ungeeignet und nicht benötigen für den Einsatz von der Entwicklung bis zur Produktion in einem org, oder in jedem Fall, wo Sie individuelle Entwicklung tun und beabsichtigen nicht, den Code zu einer großen anonymen Basis zu verteilen.

Nicht installierte Pakete: das ist, was Sie sehen, wenn Sie auf „Pakete“ im Web-UI. Diese, die wir manchmal als „Entwicklungspakete“ nennen, zu sein scheinen nur eine bequeme Möglichkeit, eine Projektdefinition zusammen zu halten.

Wie auch immer, ich die Schlussfolgerung zu kommen habe, ist, dass unser Team (kundenspezifische Entwicklung, kein ISV) benötigt keine Pakete in irgendeiner Form.

Die anderen Einsatzformen, sowohl Eclipse und Ant, stützen sich auf die Metadaten-API. In der Theorie sind sie genau die Lage, die gleichen Dinge. In Wirklichkeit scheinen sie sich ergänzen. Das Migrationstool Force.com in die Force.com IDE für Eclipse gebaut, macht Einsatz so einfach wie es sein kann (was nicht sehr) zur Verfügung und gibt Ihnen einen schönen Blick auf, was beabsichtigt sie zu implementieren. Auf der anderen Seite haben wir gesehen Ant einige Dinge tun, die IDE nicht konnte. So ist es wahrscheinlich lohnt sich beide zu lernen.

Der Prozess in Richtung wir lehnen ist alle unsere Projekte in SVN zu halten, und die SVN-Struktur wie die Projektdefinition verwenden (Eclipse mit dieser Arbeit und respektieren). Und wir verwenden Eclipse und manchmal Ant für die Migration. Keine offensichtliche Notwendigkeit für Pakete überall.

Durch die Art und Weise, eine Sache bewusst zu sein - nicht alle Komponenten migrierfähige sind. Einige Dinge müssen von Hand in der Zielumgebung neu konfiguriert werden. Ein Beispiel wäre zeitbasierte Workflows sein. Warteschlangen und Gruppen müssen auch behand erstellt, denke ich. Ebenso kann der Metadaten-API nicht direkt Feld Löschungen verarbeitet also, wenn Sie ein Feld in Ihrer Quelle gelöscht, müssen Sie es mit der Hand in dem Ziel zu löschen. Es gibt andere Fälle als gut.

Ich hoffe, das ist nützlich -

- Steve Lane

Answer 3

Ab Frühjahr '09, Seriendruck-Vorlagen nicht unterstützt werden, in Metadaten aber Satztypen sind. Sie werden Datensatztypen als XML-Element in der Datei für das Objekt zu dem sie gehören finden. Alles andere auf der Liste ist mit einer kleinen Ausnahme unterstützt. Auswahllisten-Werte für Standardfelder können nicht im Frühjahr '09 bearbeitet werden. Bleiben Sie für Nachrichten Summer '09 Feature Ankündigungen abgestimmt.

Update: Standard Auswahllisten auf Standardobjekte jetzt Metadaten (wie von API v16) ausgesetzt: http://www.salesforce.com/us/developer/ docs / api_meta / Content / meta_picklist.htm

Ansonsten Antwort Steve Lane ist ziemlich genau. Der Vorteil der Verwendung von nicht verwalteten Pakete (was Steve ruft nicht-installierten Pakete) ist, dass, wenn Sie Metadaten zu einem Paket hinzufügen, die Metadaten es hängt davon ab, wird automatisch hinzugefügt. So ist es einfacher, einen vollständigen Satz von Metadaten zu packen alle ihre Abhängigkeiten enthält. Wenn Sie wiederholen Metadaten von einem org in Bewegung sind (Sandbox) zu einer anderen (Produktion), Steve Ansatz ist wahrscheinlich der beste Weg zu gehen und sicherlich die häufigste heute. Ich benutze häufig nicht verwalteten „Entwickler“ Pakete, etwas zu bewegen ich in einem org zu einem anderen nicht verwandten org entwickelt haben. Für meine Zwecke, wie ich das Paket in der org definiert haben, wie zu einem Eclipse-Projekt / SVN gegenüber. Aber das ist wahrscheinlich nicht sinnvoll, wenn Sie Teamentwicklung über viele dev / Sandbox Orgs tun und verwenden SVN bereits.

Jesper

Answer 4

Eine weitere Möglichkeit ist die Verwendung Change Sets wenn Sie verschieben möchten Meta-Daten aus einer Sandbox zur Produktion.

Es gibt noch einige Einschränkungen, wie Änderung Sätze verwendet werden können:

  

ein Wechsel zwischen zwei Organisationen gesetzt Senden erfordert einen Einsatz   Verbindung. Derzeit werden nur Sätze Wechsel zwischen gesendet werden   Organisationen, die mit einer Produktionsorganisation angeschlossen sind, für   beispielsweise eine Produktionsorganisation und ein Sandkasten oder zwei Sandkästen   erstellt von der gleichen Organisation.

Answer 5

Aus der Dokumentation:

Ein Paket muss verwaltet werden, damit sie öffentlich auf AppExchange veröffentlicht werden, und es Upgrades zu unterstützen . Eine Organisation kann ein einziges Managed-Paket erstellen, die von vielen verschiedenen Organisationen heruntergeladen und installiert werden kann. Sie unterscheiden sich von nicht verwalteten Pakete, dass einige Komponenten gesperrt werden, so dass das verwaltete Paket später aufgerüstet werden. Unmanaged-Pakete enthalten keine gesperrten Komponenten und können nicht aktualisiert werden. Darüber hinaus verwalteten Pakete verschleiern bestimmte Komponenten (wie Apex) auf Organisationen abonnieren, um das geistige Eigentum des Entwicklers zu schützen.

Vorteil zu verwaltenden Paket wäre, dass es Sie Version leicht ermöglicht und über mehrere SFDC Organisationen Dinge zu verteilen.

Answer 6

Ich kämpfe immer noch mit diesem selbst. Weder die IDE der Migration Tool haben die wichtigsten Fragen gelöst ich konfrontiert, die wie folgt lauten:

1. Installierte Pakete können nicht zu einem Entwickler Org eingesetzt werden. Sie müssen installieren Sie sie durch eine in der Dev Org manuell ein.

   Wenn ein Paket nicht sein kann in der org (zB installiert, da es erfordert Kennwort ein, wie Marketo Verkaufs Insight oder weil sie veraltet, wie Salesforce für Google Adwords ) und unsere Anwendung hat Abhängigkeiten auf sie (wie Verweise auf Felder in Objekten, die gehören zu den Paket), dann werden wir nicht in der Lage sein, um die Anwendung zu implementieren.

   Umgehung : Wenn ein Paket kann nicht manuell in einem DEv Org jeden Entwickler installiert werden wird seine eigene Entwickler-Sandbox benötigen. Weitere Entwickler Sandkästen können von Salesforce bestellt werden. (Der Kunde bereit sein, hat für sie zu bezahlen, obwohl ...)

2. Wenn die Sandbox von der Produktion aufgefrischt wird und wir aktualisieren unsere lokales Projekt vom Server (die SVN angeschlossen ist) alle weitere Dateien / Code, der in der alten Sandkasten war, aber es ist nicht in Produktion wird in die neue Sandbox verschoben werden.

   Umgehung : alle in der Produktion müssen Änderungen in der Sandbox repliziert werden und die Entwickler Orgs. (eine Art Schmerz, aber ok ...)

Answer 7

In jeder Salesforce Produktionsbereitstellung ist der Metadaten-API eine der besseren Möglichkeiten, es zu tun. Es gibt Werkzeuge, die die Arbeit vereinfachen. Schauen Sie sich diesen Beitrag: https://www.deploypkg.com/deploy-to-production/