2010-04-01 2 views
24

Мы разрабатываем приложения для AppExchange и пытаемся найти лучший способ для управления разработкой и выпуском. Существует несколько вопросов, связанных с этим:Лучшие практики для управляемых приложений SalesForce App?

1) Префиксы для пакетов. Мы разрабатываем код в неуправляемом режиме и освобождаемся как управляемый, поэтому нам нужно добавить все префиксы пакета в код. Есть ли способ сделать это динамически во время выполнения? Прямо сейчас мы используем скрипт Ant, который останавливает нас при использовании плагина force.com IDE.

2) Файлы ресурсов ... Мы делаем некоторые вещи ajax-ey и в результате получаем несколько различных файлов ресурсов, которые мы загружаем, некоторые из которых представляют собой несколько файловых ресурсов (zip-файлы). Кто-нибудь автоматизировал создание этих ресурсов с помощью ANT, и это хорошо работает?

Наша среда кажется очень хрупкой и работает для некоторых разработчиков, а не для других; есть ли у других людей эта проблема? Как вы это разрешили?

+0

8 Голосов, 0 Ответ :) – NAVEED

ответ

13

Ненавижу говорить об этом, но похоже, что вы остановились на наилучшем подходе, о котором я знаю. Складская среда Salesforce может быть полным кошмаром для работы. Как только ваш управляемый пакет имеет префикс, на самом деле нет возврата к простому пакету без него, если вы не скрипте его, как вы это делали. Таким образом, вы найдете имя пакета, надутое по всему вашему коду, которое система добавит для вас.

Я нашел лучший способ работать с ним, чтобы сохранить «чистую» версию вашего приложения, которая будет полностью установлена ​​в dev org из Ant. Когда у вас есть код в Ant, его можно добавить в «нормальный» источник управления. Похоже, слишком много приложений большого масштаба были построены в Salesforce с несколькими членами команды, поскольку, насколько я могу судить, поддержка рабочего процесса, которая включает в себя контроль исходного кода, не так много. Они попытались добавить какой-то тип управления выпуском в конфигурацию dev org, которая сейчас находится в бета-версии, но это не показалось мне хорошим.

Я думаю, что Ant, использующий инструмент миграции Salesforce Force.com, - это способ по большей части идти. Затем, однако, как только вы захотите создать управляемый пакет, вы как бы застряли с этой базой кода, замороженной, с этим префиксом, где вам придется делать упаковочные релизы (от бета-версии и т. Д.) Изнутри упаковочной системы сам. Лучший способ обновить до песочницы (жесткий лимит один раз в месяц!), Затем разработчики вытащить из этой песочницы и развернуть в отдельные dev orgs, которые затем могут быть объединены периодически в «group dev org», раньше развертывание обратно в Песочницу (с использованием Force.com IDE или Ant), затем в Production.

Весь процесс в основном является полной катастрофой. Salesforce настолько близок к тому, что имеет супер мощную платформу, но много времени ощущается как потрясающий спортивный автомобиль без рулевого колеса.

Что касается статических ресурсов, то вы должны иметь возможность автоматизировать относительно простым способом с помощью Eclipse, чтобы вы могли развернуть их отдельно за один шаг. API также должен поддерживать его.

Я работал над некоторыми довольно большими базами кода Apex (я думаю, и надеюсь), и я действительно не вижу явного элегантного решения. Вы столкнетесь со странными комбинациями развертывания с использованием Ant в некоторых случаях, Eclipse others и т. Д.

Исходя из других сред разработки, это часто путается и просто странно. Например, это вызывает недоумение, что вы не можете легко сбрасывать базу данных за один шаг, сохраняя при этом отслеживание отношений между объектами, а затем «импортируете» ее в другую организацию за один шаг. На самом деле нам пришлось написать инструмент, который упростит извлечение всех данных при обходе объектных отношений, загрузке всех данных, рекурсивном удалении данных и т. Д. Из файла xls, потому что нам нужен простой способ тестирования в организациях.

BTW, dev orgs в основном выбрасывают организации. Мы создаем десятки из них для разных целей тестирования и сохраняем разные версии и конфигурации.

Извините, я не мог дать вам лучшие новости. Здесь может быть больше гуру, который может указать на элегантный способ управления упаковкой, и я буду так же заинтересован в вас, как в ответе! Вы можете направить меня по адресу suprasphere --- в --- gmail, если вы хотите сочувствовать! :)

+0

Возможно, стоит обратить внимание на то, как можно использовать способы изменения для решения этой проблемы. Это последнее дополнение к Salesforce.com. Я не думаю, что они были доступны, когда был дан ответ. – Born2BeMild

+0

Изменения в модуле разработчика не могут использоваться в приложениях разработчика (там, где вы создаете приложения AppExchange), поэтому в этом случае это не поможет. – ceiroa

0

Мы недавно переключились на использование префиксного менеджера вместо выполнения ант-замещений.

Вот наш код.

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; 
    } 
} 

В основном это попытка запроса (один раз) к таблице с префиксным именем. Если он не существует, мы находимся в неуправляемом режиме без префиксов пакетов. Если это произойдет, то мы установим префикс соответствующим образом. getObjName - это удобство, потому что PrefixMgr.getObjName('MyObject__c') легче читать (esp в строке concat), чем PrefixMgr.getObjPrefix() + 'MyObject__c'.

Заинтересованы в мыслях и замечаниях.

+3

Зачем вам нужно добавить префикс к своим запросам? Только код за пределами вашего пакета, который ссылается на объекты/классы в пакете, должен использовать пространство имен. См. Http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_classes_namespace_prefix.htm –

+0

Оказывается, нам не нужно было это делать, и мы не использовали это. Нам была дана некоторая дезинформация, и это заняло некоторое время, чтобы понять это :). – Fiid

Смежные вопросы