Salesforce - как выполнить развертывание между средами (песочница, Live и т. Д.) - PullRequest
25 голосов
/ 23 февраля 2009

Мы пытаемся настроить правильный процесс развертывания.

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

  1. Копировать и вставить - мы не хотим этого делать
  2. Использование механизма «Пакет», встроенного в веб-интерфейс Salesforce
  3. Опция Eclipse Force IDE "Развертывание на сервер"
  4. Муравьиный скрипт (еще не пробовал)

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

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

Мы собираемся развернуть следующие элементы:

  • Apex Classes

  • Триггеры Apex

  • * 1031 рабочих процессов *

  • Шаблоны электронной почты

  • Шаблоны MailMerge - кажется, не могу найти их в Eclipse

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

  • Макет страницы

  • RecordTypes (кажется, не может найти их на веб-сайте или в Eclipse)

  • PickList пунктов?

  • SControls

Ответы [ 7 ]

15 голосов
/ 20 марта 2009

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

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

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

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

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

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

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

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

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

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

- Стив Лейн

15 голосов
/ 23 февраля 2009

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

Для справки:

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

2 голосов
/ 29 февраля 2012

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

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

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

2 голосов
/ 25 марта 2009

Начиная с 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.

Jesper

0 голосов
/ 07 сентября 2016

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

0 голосов
/ 27 ноября 2012

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

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

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

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

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

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

0 голосов
/ 17 июля 2009

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

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

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

...