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

Ответ 1

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

Я нашел лучший способ работать с ним - сохранить "чистую" версию вашего приложения, которая будет установлена ​​в 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 и т.д.

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

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

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

Ответ 2

Недавно мы переключились на использование префиксного менеджера вместо ant подстановок.

Вот наш код.

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'.

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