Регистрация  |  Вход

Перенос кода, настроек и данных между разными учетными записями

Коллеги, привет

Есть следующая ситуация - партнер, который будет внедрять нам SF, предлагает для ускорения и удешевления процесса сделать следующий трюк: MVP (пилот) делать в своей партнерской учетной записи, не создавая клиентскую запись.
А после принятия пилота создать клиентскую запись, перенести туда все, и дальше продакшн иметь уже на нашей, клиентской стороне.
Вопрос - работающий ли это подход, или средство для подсаживания на крючок?
Пошарив по форумам, сделал для себя вывод, что перенос кода и настроек из орга в орг делается элементарно.
Вопроса два:
1. Не совсем уверен, верно ли я понял, что этот перенос можно делать не только в рамках одной компании, но и между партнерской и клиентской учеткой?
2. По данным вопрос - насколько это просто делается, реально ли, скажем, в пределах недели такой перенос сделать? На зарубежных ресурсах пишут какие-то нюансы про поддержание id и иерархий между записями, но не до конца понятно, насколько это трудозатратная операция.

Заранее спасибо за разъяснения.

dm
Коллеги, привет

Есть следующая ситуация - партнер, который будет внедрять нам SF, предлагает для ускорения и удешевления процесса сделать следующий трюк: MVP (пилот) делать в своей партнерской учетной записи, не создавая клиентскую запись.
А после принятия пилота создать клиентскую запись, перенести туда все, и дальше продакшн иметь уже на нашей, клиентской стороне.
Вопрос - работающий ли это подход, или средство для подсаживания на крючок?
Пошарив по форумам, сделал для себя вывод, что перенос кода и настроек из орга в орг делается элементарно.
Вопроса два:
1. Не совсем уверен, верно ли я понял, что этот перенос можно делать не только в рамках одной компании, но и между партнерской и клиентской учеткой?
2. По данным вопрос - насколько это просто делается, реально ли, скажем, в пределах недели такой перенос сделать? На зарубежных ресурсах пишут какие-то нюансы про поддержание id и иерархий между записями, но не до конца понятно, насколько это трудозатратная операция.

Заранее спасибо за разъяснения.

Привет.
Непривычными понятиями орудуешь для нашего брата SF программиста.
Но в принципе понятно.
Учетная запись это ты про орги - вот тут вроде про это написано
https://developer.salesforce.com/page/An_Introduction_to_Environments
То что ты описал про "подсаживание на крючек" - это обычный процесс разработки - для разработки используется dev org и они бесплатные и их может создать любой, есть его расширенная по лимитам версия - partner dev org (могут регать партнеры). После того как бизнес логика создана и протестирована ее переносят на production org. Разрабатывать на production org физически не возможно! на него можно только деплоить код. Так что то что вам предложили это нормально. Естественно вам должны предоставить доступ на данный орг (минимум для тестрования), а чтобы совсем себя обезопасить я вам настоятельно советую сделать свой git репозиторий и попросить разработчика (компанию которая будет разрабатывать) чтобы они подключили проект к данному git (так ваш код никуда не денется, даже если исполнитель окажется недобросовестный).
Вопросы 1 и 2 уже не имеют особого смысла - перенос это часть процесса разработки и может делаться как в течении 5 минут, так и в течении бОльшего времени что зависит от размера кодовой базы, настроек и кривости рук разработчиков.

Привет.
Непривычными понятиями орудуешь для нашего брата SF программиста. 
Но в принципе понятно. 
Учетная запись это ты про орги - вот тут вроде про это написано
https://developer.salesforce.com/page/An_Introduction_to_Environments
То что ты описал про "подсаживание на крючек" - это обычный процесс разработки - для разработки используется dev org и они бесплатные и их может создать любой, есть его расширенная по лимитам версия - partner dev org (могут регать партнеры). После того как бизнес логика создана и протестирована ее переносят на production org. Разрабатывать на production org физически не возможно! на него можно только деплоить код. Так что то что вам предложили это нормально. Естественно вам должны предоставить доступ на данный орг (минимум для тестрования), а чтобы совсем себя обезопасить я вам настоятельно советую сделать свой git репозиторий и попросить разработчика (компанию которая будет разрабатывать) чтобы они подключили проект к данному git (так ваш код никуда не денется, даже если исполнитель окажется недобросовестный).
Вопросы 1 и 2 уже не имеют особого смысла - перенос это часть процесса разработки и может делаться как в течении 5 минут, так и в течении бОльшего времени что зависит от размера кодовой базы, настроек и кривости рук разработчиков.


Если я правильно понял - партнер предлагает Вам не тратить сейчас деньги на лицензию, а делать все на его (партнера) учетке(орге).

1. Можно, как минимум ANT'ом.
2. Сам процесс переноса относительно недолог - до 1 дня, если очень много разного кода, который накатывается не на чистую оргу. По нюансы с записями не совсем понятно - если это MVP, то реальные данные в нем появятся уже на Вашей учетке, после переноса из орги партнера, соответственно, иерархия записей не будет играть роли т.к. записи появятся только после переноса.

Если у Вас стандартная Sales/Service и т.п. орга salesforce и Вы не планируете использовать какие-то приложения от партнера, тогда есть возможность Вам самому создать бесплатную Developer Org, одну учетку оставить себе, вторую учетку отдать партнеру(в дев орге максимум можно иметь две учетки с лицензией "Salesforce" - полной лицензией).

Подсаживания "на крючок", лично я, не вижу - единственный минус, Вы не будете иметь контроля над кодом - т.е. если в процессе создания MVP у вас случится конфликт и Вы захотите забрать все то, что сделал по вашей задаче партнер - нужно будет с ним об этом договариваться. В случае же Вашей учетки, весь код будет на ней, договариваться ни о чем не нужно будет.

Если я правильно понял - партнер предлагает Вам не тратить сейчас деньги на лицензию, а делать все на его (партнера) учетке(орге).

1. Можно, как минимум ANT'ом.
2. Сам процесс переноса относительно недолог - до 1 дня, если очень много разного кода, который накатывается не на чистую оргу. По нюансы с записями не совсем понятно - если это MVP, то реальные данные в нем появятся уже на Вашей учетке, после переноса из орги партнера, соответственно, иерархия записей не будет играть роли т.к. записи появятся только после переноса.

Если у Вас стандартная Sales/Service и т.п. орга salesforce и Вы не планируете использовать какие-то приложения от партнера, тогда есть возможность Вам самому создать бесплатную Developer Org, одну учетку оставить себе, вторую учетку отдать партнеру(в дев орге максимум можно иметь две учетки с лицензией "Salesforce" - полной лицензией).

Подсаживания "на крючок", лично я, не вижу - единственный минус, Вы не будете иметь контроля над кодом - т.е. если в процессе создания MVP у вас случится конфликт и Вы захотите забрать все то, что сделал по вашей задаче партнер - нужно будет с ним об этом договариваться. В случае же Вашей учетки, весь код будет на ней, договариваться ни о чем не нужно будет.

Спасибо большое за разъяснения! Непривычные понятия - это отсутствие компетенции в продукте
Про перенос кодовой базы в принципе все понятно
Но основной вопрос был именно по данным. Подразумевается, что MVP будет работать достаточно продолжительное время (3 месяца вполне может быть), соответственно там накопится куча информации по пользователям. С переносом данных из орга партнера в орг клиента могут быть какие-то непреодолимые коряги?

dm
Спасибо большое за разъяснения! Непривычные понятия - это отсутствие компетенции в продукте :)
Про перенос кодовой базы в принципе все понятно
Но основной вопрос был именно по данным. Подразумевается, что MVP будет работать достаточно продолжительное время (3 месяца вполне может быть), соответственно там накопится куча информации по пользователям. С переносом данных из орга партнера в орг клиента могут быть какие-то непреодолимые коряги?

С переносом данных тоже не должно быть проблем.
Есть нюансы, но это задача обычная для SF, так что для опытного разработчика тут проблем не должно быть.
Если все же проблемы возникнут - то можно написать об этом здесь, на форуме есть люди которые даже тулы свои пишут для сложной миграции данных.

С переносом данных тоже не должно быть проблем.
Есть нюансы, но это задача обычная для SF, так что для опытного разработчика тут проблем не должно быть.
Если все же проблемы возникнут - то можно написать об этом здесь, на форуме есть люди которые даже тулы свои пишут для сложной миграции данных.