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

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

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

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

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

24
задан RichVel 2 January 2014 в 13:52
поделиться

2 ответа

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

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

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

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

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

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

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

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

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

13
ответ дан 29 November 2019 в 00:27
поделиться

Недавно мы перешли на использование диспетчера префиксов вместо подстановки муравьев.

Вот наш код.

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

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

0
ответ дан 29 November 2019 в 00:27
поделиться
Другие вопросы по тегам:

Похожие вопросы: