Salesforce - как развертывать среду (песочницы, Live и т.д.)

Ответ 1

Я рекомендую Инструмент миграции Force.com.

Для справки:

• Документация инструмента миграции Force.com
• Руководство по средствам миграции

Инструмент миграции позволяет использовать ant цели для перемещения метаданных между организациями salesforce.com.

Ответ 2

Я могу поговорить с этим из недавнего болезненного опыта.

Упаковка: это очень старый метод, который предшествует API метаданных, на котором полагаются как Ant, так и Eclipse. По нашему опыту, упаковка только выгоды заключается в определении вашего проекта. Если вы используете Eclipse (что мы делаем, и я рекомендую), вы можете определить свой проект как основанный на определенном пакете. Пока вы не забудете добавить новые компоненты в свой пакет, ваш проект висит вместе

Одна вещь, которая сбивала нас с толку некоторое время, кстати, - это много использования пакета. Мы отметили следующее:

Установленные пакеты: они входят в управляемые и неуправляемые вкусы и действительно, по словам недавней публикации на досках SFDC, для независимых поставщиков программного обеспечения для развертывания их материалов в различные неизвестные организации "там". Как управляемые, так и неуправляемые пакеты имеют ограничения, которые делают их непригодными и ненужными для развертывания от разработки до производства в рамках организации или в любом случае, когда вы выполняете индивидуальную разработку и не собираетесь распространять код на большую анонимную базу.

Не установленные пакеты: это то, что вы видите, когда вы нажимаете "Пакеты" в веб-интерфейсе. Эти, которые мы иногда называем "пакетами разработки", кажутся просто удобным способом совместного определения проекта.

В любом случае вывод, к которому я обращаюсь, заключается в том, что наша команда (нестандартная разработка, а не ISV) не нуждается в пакетах в любой форме.

Другие формы развертывания, как Eclipse, так и Ant, зависят от API метаданных. Теоретически они способны на одно и то же. На самом деле они кажутся взаимодополняющими. Инструмент миграции Force.com, встроенный в Force.com IDE для Eclipse, делает развертывание настолько простым, насколько это возможно (что не так), и дает вам хороший взгляд на то, что он намерен развернуть. С другой стороны, мы видели, что Ant сделать некоторые вещи, которые не удалось IDE. Поэтому, вероятно, стоит изучить оба.

Процесс, к которому мы стремимся, состоит в том, чтобы сохранить все наши проекты в SVN и использовать структуру SVN в качестве определения проекта (Eclipse будет работать с этим и уважать его). И мы используем Eclipse, а иногда Ant для миграции. Нет очевидной потребности в пакетах в любом месте.

Кстати, еще одна вещь, о которой нужно знать - не все компоненты переносятся. Некоторые вещи должны быть переконфигурированы вручную в целевой среде. Одним из примеров может быть временные рабочие процессы. Я думаю, что очереди и группы также должны быть созданы с учетом поведения. Аналогично, API метаданных не может напрямую обрабатывать удаления полей, поэтому, если вы удалили поле в своем источнике, вам нужно удалить его вручную в целевом объекте. Существуют и другие случаи.

Надеюсь, что полезно -

- Стив Лейн

Ответ 3

Как и в случае с Spring '09, шаблоны слияния не поддерживаются в метаданных, но существуют типы записей. Вы найдете типы записей в качестве элемента XML в файле для объекта, к которому они принадлежат. Все остальное в вашем списке поддерживается с небольшим исключением. Значения списков для стандартных полей не могут быть отредактированы в Spring '09. Следите за новостями о анонсах функций Summer'09.

Обновление. Стандартные подборщики стандартных объектов теперь становятся метаданными (как API v16): http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_picklist.htm

В противном случае ответ Стива Лейна довольно точен. Преимущество использования неуправляемых пакетов (то, что Стив называет не установленными пакетами) состоит в том, что при добавлении метаданных в пакет метаданные, от которых он зависит, будут автоматически добавляться. Таким образом, легче получить полный набор метаданных, содержащих все его зависимости. Если вы неоднократно перемещаете метаданные из одной организации (песочницы) в другую (производство), подход Стива, вероятно, лучший способ пойти и, безусловно, самый распространенный сегодня. Я часто использую неуправляемые пакеты "разработчика", чтобы переместить что-то, что я разработал в одной организации, к другой несвязанной организации. Для моей цели мне нравится иметь пакет, определенный в организации, а не проект Eclipse/SVN. Но, вероятно, это не имеет смысла, если вы занимаетесь разработкой команды во многих организациях dev/sandbox и уже используете SVN.

Джеспер

Ответ 4

Другим вариантом является использование Change Sets, если вы хотите переместить метаданные из песочницы в производство.

В настоящее время существуют некоторые ограничения на использование наборов изменений:

Отправка набора изменений между двумя организациями требует развертывания подключение. В настоящее время наборы изменений могут быть отправлены только между организации, которые связаны с производственной организацией, для пример, организация производства и песочница или две песочницы созданный из той же организации.

Ответ 5

Из документов:

Необходимо, чтобы пакет был опубликован публично на AppExchange и для поддержки обновлений. Организация может создать единый управляемый пакет, который может быть загружен и установлен многими различными организациями. Они отличаются от неуправляемых пакетов тем, что некоторые компоненты заблокированы, что позволяет впоследствии обновить управляемый пакет. Неуправляемые пакеты не включают заблокированные компоненты и не могут быть обновлены. Кроме того, управляемые пакеты обфускают определенные компоненты (например, Apex) для подписных организаций, чтобы защитить интеллектуальную собственность разработчика.

Преимущество управляемого пакета заключается в том, что он позволяет вам легко изменять и распространять информацию в нескольких организациях SFDC.

Ответ 6

Я все еще с этим борюсь. Ни в среде IDE инструмента миграции не решаются основные проблемы, с которыми я сталкиваюсь:

• Установленные пакеты не могут быть развернуты в Оргрукции разработчиков. Вы должны установите их вручную один за другим в Dev Org.

  Если пакет не может быть установленный в org (например, потому что для этого требуется пароль, например Marketo Sales Insight, или потому, что он устарел, как Salesforce для Google Adwords), и наше приложение имеет зависимости на нем (например, ссылки на поля в объектах, принадлежащих пакет), то мы не сможем развернуть приложение.

  Временное решение: если пакет не может быть установлен вручную в DEV Org для каждого разработчика потребуется его собственная песочница разработчика. Дополнительные песочницы для разработчиков можно заказать у Salesforce. (Клиент должен быть готов заплатить за них, хотя...)

• Когда песочница обновляется с производства, и мы обновляем нашу локальный проект (который подключен к SVN) с сервера дополнительные файлы/код, которые были в старой песочнице, но это не производство будет перенесено в новую Песочницу.

  Обходное решение: все изменения, внесенные в производство, должны быть воспроизведены в Песочнице и Разработчики Orgs. (Вид боли, но нормально...)

Ответ 7

В любом развертывании производства Salesforce API метаданных является одним из лучших вариантов для этого. Есть инструменты, которые упрощают работу. Отправляй сообщение: https://www.deploypkg.com/deploy-to-production/