Разверните большую базу кода для нового Salesforce dev org

В настоящее время у нас есть несколько пользователей, пытающихся разработать код для одного приложения в salesforce. У нас есть Продукт уже на месте, и у него уже много кода. То, что мы пытаемся сделать, - найти простой в использовании механизм, который можно использовать для развертывания нашей центральной базы кода для нескольких разработчиков, не связанных между собой.

Что мы имеем -

  1. База данных SVN, где весь код сохранен.
  2. Множество несвязанных разработчиков.
  3. Текущая Org и база кода имеют множество шаблонов Apex, Pages, Email, отчетов, панелей мониторинга, Workflow, профилей, триггеров и большинства стандартных функций, а также функций Custom Salesforce.

Что мы хотим сделать - 1. Упрощенный механизм или способ, который может быть использован для развертывания всей организации для некоторых нереализованных организаций-разработчиков/партнеров.

То, что мы пробовали - 1. Мы попробовали то же самое с использованием Eclipse, и для завершения активности требуется почти 6-7 часов, и это тоже имеет вероятность упустить вещи из-за зависимости между несколькими компиляторами. Очень большая головная боль при таком подходе. 2. Используйте инструмент Ant Migration. Используя Force.com Migration tool и Ant-команды, мы попробовали развернуть в первый раз несвязанные org. Но это привело к по меньшей мере 400 ошибкам -500 по командной строке. Не знаете, как это сделать. У нас есть более простой способ, или нам нужно идти вперед и решать каждый вопрос по одному.

У нас нет обеспечения для наборов изменений или Sandbox/Production org, поскольку мы создаем пакет для нескольких пользователей. Пожалуйста, дайте мне знать о любых других возможных способах, которые можно использовать для переноса огромной базы кода (стандартных + пользовательских элементов SF) в любой несвязанный dev org.

Любая помощь будет оценена по достоинству.

Спасибо, Каушик

1 ответ

Когда нам нужно вручную развернуть проект SF в новый org (или обновить текущий вручную), мы обычно развертываем части проекта в такой последовательности:

  1. статические res
  2. этикетки
  3. группы
  4. роли
  5. печатный бланк
  6. документы
  7. OBJETCS
  8. вкладки
  9. Программы
  10. Эл. адрес
  11. классы
  12. страницы
  13. компоненты
  14. макеты
  15. триггеры
  16. Рабочие процессы
  17. отчеты
  18. dashbords
  19. макеты домашней страницы
  20. компоненты главной страницы
  21. профили
  22. наборы разрешений

Это позволяет избежать ошибок, связанных с зависимостями в компонентах проекта. Также мы используем некоторые инструменты для непрерывной интеграции (например, Jenkins, который разворачивает все изменения (которые передаются в репозиторий) в CI org и каждую ночь развертывает сборки на QA org).

licensed under cc by-sa 3.0 with attribution.