Ненавижу говорить об этом, но похоже, что вы остановились на наилучшем подходе, о котором я знаю. Складская среда 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, если вы хотите сочувствовать! :)
8 Голосов, 0 Ответ :) – NAVEED