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

Question

Мы изучаем настройку надлежащего процесса развертывания.

Из того, что я прочитал, кажется, есть 4 способа сделать это.

1. Copy & Paste - Мы не хотим, чтобы это сделать
2. Использование механизма "Package", встроенный в веб-интерфейс Salesforce
3. Затмения Force IDE "Deploy на сервер" вариант
4. Ant Сценарий (еще не пробовал еще один)

У кого-нибудь есть совет по ограничению различных методов.

Можете ли вы включить все в пакет веб-интерфейса?

Мы ищем, чтобы развернуть следующие пункты:

• Классы Apex

• Apex Триггеры

рабочие процессы

• Email Шаблоны

• MailMerge Шаблоны - Не похоже, чтобы найти их в Затмении

• Пользовательские поля

• Page Layout

• RecordTypes (не могу найти их в веб-сайт или Eclipse)

• Элементы PickList?

• SControls

Answer 1

Я рекомендую Force.com Migration Tool.

Для справки:

• Force.com Migration Tool Documentation
• Migration Tool Guide

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

Answer 2

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

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

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

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

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

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

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

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

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

Надеется, что это полезно -

- Steve Lane

Answer 3

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

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

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

Jesper

Answer 4

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

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

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

Answer 5

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

Есть в настоящее время некоторые ограничения относительно того, как можно использовать наборы изменений:

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

Answer 6

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

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

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

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

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

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

Answer 7

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