Best Practices für die Entwicklung von Managed SalesForce-Apps?

Question

Wir entwickeln Anwendungen für AppExchange und versuchen herauszufinden, wie das Entwicklungs- und Veröffentlichungsmanagement am besten funktioniert. Es gibt mehrere Probleme dabei:

1) Paket Präfixe. Wir entwickeln Code im nicht verwalteten Modus und veröffentlichen ihn als verwaltet. Daher müssen wir alle Paketpräfixe in den Code einfügen. Gibt es eine Möglichkeit, dies dynamisch zur Laufzeit zu tun? Im Moment verwenden wir ein Ant-Skript, das uns davon abhält, vom force.com-IDE-Plugin zu profitieren.

2) Ressourcendateien ... Wir machen etwas Ajax-ey-Zeug und als Ergebnis haben wir ein paar verschiedene Ressourcendateien hochgeladen, von denen einige mehrere Dateiressourcen (zip-Dateien) sind. Hat jemand den Aufbau dieser Ressourcen mit ANT automatisiert, und funktioniert das gut?

Unsere Umgebung scheint sehr fragil und funktioniert für einige Entwickler und nicht für andere; haben andere Leute dieses Problem? Wie hast du es gelöst?

Answer 1

Ich hasse es zu sagen, aber es klingt, als ob du dich auf den besten Ansatz eingelassen hast, den ich kenne. Die Salesforce-Verpackungsumgebung kann ein absoluter Albtraum sein, mit dem man arbeiten kann. Sobald Ihr verwaltetes Paket ein Präfix hat, gibt es wirklich kein einfaches Paket mehr, wenn Sie es nicht wie gewohnt skripten. Sie werden also den Paketnamen in Ihrem Code finden, den das System für Sie hinzufügen wird.

Ich habe den besten Weg gefunden, damit zu arbeiten ist es, eine "reine" Version Ihrer App zu behalten, die sauber in eine Dev-Organisation innerhalb von Ant installiert wird. Sobald Sie den Code in Ant haben, kann er in "normale" Quellcodeverwaltung hinzugefügt werden. Es scheint nicht, dass in Salesforce mit mehreren Teammitgliedern zu viele größere Apps erstellt wurden, denn soweit ich das beurteilen kann, gibt es kaum Unterstützung für einen Workflow mit Quellcodeverwaltung. Sie haben versucht, einer Dev-Organisationskonfiguration, die jetzt in der Beta-Version ist, eine Art Release-Management hinzuzufügen, aber das schien gar nicht so gut zu sein.

Ich denke Ant mit dem Salesforce Force.com Migrationstool ist der Weg, um den größten Teil zu gehen. Sobald Sie jedoch ein verwaltetes Paket erstellen möchten, bleiben Sie bei dieser Code-Basis eingefroren, mit diesem Präfix, wo Sie dann Packaging-Releases (aus der Beta usw.) innerhalb des Verpackungssystems ausführen müssen selbst. Der beste Weg ist es, auf Sandbox zu aktualisieren (harte Grenze von einmal pro Monat !!), dann Entwickler aus dieser Sandbox ziehen und in einzelne Dev-Organisationen, die dann regelmäßig in eine "Gruppen-Dev-Org" verschmolzen werden können, zu verteilen Bereitstellen in der Sandbox (mit Force.com IDE oder Ant) und dann in Production.

Der gesamte Prozess ist im Grunde eine vollständige Katastrophe. Salesforce ist so nah an einer super starken Plattform, aber die meiste Zeit fühlt sich wie ein toller Sportwagen ohne Lenkrad an.

Soweit statische Ressourcen, sollten Sie in der Lage sein, relativ einfach mit Eclipse zu automatisieren, so dass Sie diese separat in einem Schritt bereitstellen können. Die API sollte dies auch unterstützen.

Ich habe an einigen ziemlich großen Apex-Code-Basen gearbeitet (ich denke, und hoffe), und es gibt wirklich keine offensichtlich elegante Lösung, fürchte ich. Sie werden mit seltsamen Kombinationen von Bereitstellung mit Ant in einigen Fällen stecken, Eclipse andere usw.

Kommen aus anderen Entwicklungsumgebungen, es ist oft verwirrend und einfach seltsam. Zum Beispiel ist es verwirrend, dass Sie die Datenbank nicht einfach in einem Schritt ablegen können, während Sie die Beziehungen zwischen Objekten verfolgen und sie dann in einem Schritt in eine andere Organisation "importieren". Wir mussten ein Werkzeug schreiben, das es einfach macht, alle Daten zu extrahieren, während man Objektbeziehungen durchläuft, alle Daten lädt, Daten rekursiv löscht usw. aus einer xls-Datei, weil wir einen einfachen Weg zum Testen in Organisationen brauchen.

BTW, Dev-Orgs sind im Grunde weg Orgs wegwerfen. Wir erstellen Dutzende von ihnen für verschiedene Testzwecke und um verschiedene Versionen und Konfigurationen zu behalten.

Leider konnte ich Ihnen keine besseren Nachrichten geben. Vielleicht gibt es hier mehr Guru, die auf eine elegante Art und Weise, Verpackungen zu verwalten, hinweisen können, und ich werde mich genauso für dich wie für die Antwort interessieren! Sie können mir eine E-Mail an suprasphere --- at --- gmail schicken, wenn Sie Mitleid haben wollen! :)

Answer 2

Wir haben vor kurzem auf die Verwendung eines Präfix-Managers umgestellt, anstatt Ameisen zu ersetzen.

Hier ist unser Code.

public class PrefixMgr { 
    private static string objPrefix = null; 

    public static string getObjPrefix() { 
     if(objPrefix == null) { 
      try { 
       Database.query('select MyColumn__c from my_prefix__MySmallTable__c'); 
       objPrefix = 'my_prefix__'; 
      } 
      catch(Exception e) { 
       objPrefix = ''; 
      } 
     } 

     return objPrefix; 
    } 

    public static string getAppPrefix() { 
     return 'my_prefix__'; 
    } 

    public static string getObjName(string inp) { 
     return getObjPrefix() + inp; 
    } 
} 

Im Grunde versucht dies eine Abfrage (einmal) gegen eine Tabelle mit dem vorangestellten Namen. Wenn es nicht vorhanden ist, befinden wir uns im nicht verwalteten Modus ohne Paket-Präfixe. Wenn es gelingt, dann setzen wir das Präfix entsprechend. getObjName ist eine Annehmlichkeit, weil PrefixMgr.getObjName('MyObject__c') einfacher zu lesen ist (besonders in einer Zeichenkette) als PrefixMgr.getObjPrefix() + 'MyObject__c'.

Interesse an Gedanken und Kommentaren.