Лучшие практики для управляемой разработки приложений SalesForce?

Question

Мы разрабатываем приложения для AppExchange и пытаемся найти лучший способ управления разработкой и выпуском. Есть несколько проблем вокруг этого:

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

Вот наш код.

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') легче читать (особенно в строке concat), чем PrefixMgr.getObjPrefix() + 'MyObject__c'.

Интересуются мыслями и комментариями.