Salesforce - Как выполнять развертывание в разных средах (Изолированные среды, Live и т.д.)

Question

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

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

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

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

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

Мы планируем внедрить следующие элементы:

• Высшие классы

• Триггеры Apex

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

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

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

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

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

• Типы записей (похоже, не могу найти их на веб-сайте или в Eclipse)

• Элементы списка выбора?

• Элементы управления бра

Answer 1

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

Для справки:

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

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

Answer 2

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

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

Кстати, одна вещь, которая некоторое время ставила нас в тупик, - это множество применений package .Мы отметили следующее:

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

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

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

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

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

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

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

-- Стив Лейн

Answer 3

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

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

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

Джеспер

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

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

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

Answer 7

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