Salesforce - Как выполнять развертывание в разных средах (Изолированные среды, Live и т.д.)
-
05-09-2019 - |
Вопрос
Мы изучаем возможность настройки надлежащего процесса развертывания.
Из того, что я прочитал, кажется, есть 4 способа сделать это.
- Копировать и вставлять - Мы не хотим этого делать
- Использование механизма "Пакет", встроенного в веб-интерфейс Salesforce
- Опция Eclipse Force IDE "Развернуть на сервер"
- Муравьиный скрипт (этот еще не пробовал)
Есть ли у кого - нибудь советы по ограничению различных методов?
Можете ли вы включить все в пакет веб-интерфейса?
Мы планируем внедрить следующие элементы:
Высшие классы
Триггеры Apex
Рабочие процессы
Шаблоны электронной почты
Шаблоны MailMerge - похоже, не могу найти их в Eclipse
Пользовательские поля
Макет страницы
Типы записей (похоже, не могу найти их на веб-сайте или в Eclipse)
Элементы списка выбора?
Элементы управления бра
Решение
Я рекомендую Force.com Инструмент миграции.
Для справки:
Инструмент миграции позволяет вам использовать цели ant для перемещения ваших метаданных между salesforce.com организациями.
Другие советы
Я могу говорить об этом, исходя из недавнего болезненного опыта.
Упаковка:это очень старый метод, который предшествовал API метаданных, на который полагаются как Ant, так и Eclipse.По нашему опыту, единственное преимущество упаковки заключается в определении вашего проекта.Если вы используете Eclipse (что мы делаем, и я рекомендую), вы можете определить свой проект как основанный на определенном пакете.Пока вы не забываете добавлять новые компоненты в свой пакет, ваш проект остается неизменным
Кстати, одна вещь, которая некоторое время ставила нас в тупик, - это множество применений package .Мы отметили следующее:
Установленные пакеты:они бывают управляемыми и неуправляемыми, и на самом деле, как говорится в недавнем посте на досках SFDC, предназначены для того, чтобы провайдеры могли внедрять свои материалы в различные неизвестные организации "где-то там".Как управляемые, так и неуправляемые пакеты имеют ограничения, которые делают их непригодными и ненужными для развертывания от разработки до производства в рамках организации или в любом случае, когда вы занимаетесь пользовательской разработкой и не собираетесь распространять код на большой анонимной базе.
Неустановленные пакеты:это то, что вы видите, когда нажимаете "Пакеты" в веб-интерфейсе.Они, которые мы иногда называем "пакетами разработки", кажутся просто удобным способом объединить определение проекта.
В любом случае, вывод, к которому я прихожу, заключается в том, что нашей команде (пользовательская разработка, а не ISV) не нужны пакеты ни в какой форме.
Другие формы развертывания, как Eclipse, так и Ant, полагаются на API метаданных.Теоретически они способны на совершенно одно и то же.На самом деле они, по-видимому, дополняют друг друга.Force.com Инструмент миграции, встроенный в Force.com IDE для Eclipse, упрощает развертывание настолько, насколько это возможно (что не очень), и дает вам наглядное представление о том, что он намеревается развернуть.С другой стороны, мы видели, как Ant делал некоторые вещи, которые не удавались IDE.Так что, вероятно, стоит изучить и то, и другое.
Процесс, к которому мы склоняемся, заключается в том, чтобы сохранить все наши проекты в SVN и использовать структуру SVN в качестве определения проекта (Eclipse будет работать с этим и уважать его).И мы используем Eclipse, а иногда и Ant для миграции.Нигде нет очевидной необходимости в пакетах.
Кстати, еще одна вещь, о которой следует знать - не все компоненты поддаются миграции.Некоторые вещи должны быть перенастроены вручную в целевой среде.Одним из примеров могут быть рабочие процессы, основанные на времени.Я думаю, очереди и группы также необходимо создавать вручную.Аналогично, API метаданных не может напрямую обрабатывать удаления полей, поэтому, если вы удалили поле в своем источнике, вам нужно удалить его вручную в целевом.Есть и другие случаи.
Надеюсь, это полезно --
-- Стив Лейн
Начиная с весны '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.
Джеспер
Другой вариант заключается в использовании Наборы изменений если вы хотите переместить метаданные из изолированной среды в рабочую.
В настоящее время существуют некоторые ограничения на то, как можно использовать наборы изменений:
Для отправки набора изменений между двумя организациями требуется развертывание подключение.В настоящее время наборы изменений могут быть отправлены только между организациями, которые связаны с производственной организацией, например производственная организация и изолированная среда или две изолированные среды созданные в одной организации.
Из документов:
Пакетом необходимо управлять, чтобы он был публично опубликован на AppExchange и поддерживал обновления.Организация может создать единый управляемый пакет, который может быть загружен и установлен многими различными организациями.Они отличаются от неуправляемых пакетов тем, что некоторые компоненты заблокированы, что позволяет обновить управляемый пакет позже.Неуправляемые пакеты не включают заблокированные компоненты и не могут быть обновлены.В дополнение, управляемые пакеты запутывают определенные компоненты (например, Apex) в организациях-подписчиках, чтобы защитить интеллектуальную собственность разработчика.
Преимущество управляемого пакета будет заключаться в том, что он позволяет вам легко создавать версии и распространять их в нескольких организациях SFDC.
Я сам все еще борюсь с этим.Ни одна из IDE инструмента миграции не решила основные проблемы, с которыми я сталкиваюсь, а именно:
Установленные пакеты не могут быть развернуты в Организации разработчиков.Вы должны установить их вручную один за другим в организации разработчиков.
Если пакет не может быть установлен в организации (например, потому что для него требуется пароль, например Анализ продаж Marketo, или потому, что он устарел, например Salesforce для Google Adwords) и наше приложение имеет зависимости от него (например, ссылки на поля в объектах, принадлежащих пакету ), тогда мы не сможем развернуть приложение.
Обходной путь:если пакет не может быть установлен вручную в организации разработчиков, каждому разработчику понадобится его собственная песочница для разработчиков.Дополнительные песочницы для разработчиков их можно заказать в системе Salesforce. (Хотя клиент должен быть готов заплатить за них ...)
Когда песочница обновляется с производства, и мы обновите наш локальный проект (который подключен к SVN) с сервера все дополнительные файлы / код, которые были в старой изолированной среде, но их там нет производство будет перенесено в новую изолированную среду.
Обходной путь:все изменения, внесенные в рабочей среде, должны быть воспроизведены в изолированной среде и у Организаций-разработчиков. (Немного больно, но ладно ...)
В любом производственном развертывании Salesforce API метаданных является одним из лучших вариантов для этого.Есть инструменты, которые упрощают работу.Ознакомьтесь с этим постом : https://www.deploypkg.com/deploy-to-production/