Salesforce - Как Развернуться между Средами (Песочницы, Живые и т.д.)

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

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

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

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

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

Так или иначе, заключение, к которому я приезжаю, состоит в том, что нашей команде (заказная разработка ПО, не независимый поставщик программного обеспечения) не нужны пакеты ни в какой форме.

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

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

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

Hope это полезно -

- Steve Lane

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

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

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

Jesper

Из документации:

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

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