Разработка гибкого стиля с Dynamics CRM 2011

Question

Моя команда отвечает за CRM-систему среднего размера (~ 1000 пользователей). В настоящее время наш CRM построен на базе Java Servlets, и мы переходим к Microsoft Dyanmics CRM 2011. Нам нужно будет сделать множество настроек в соответствии с нашей бизнес-логикой и нормативными требованиями.

В настоящее время мы выполняем двухнедельный выпуск функций и исправлений ошибок (свопите старые файлы jar/jsp и замените их новыми). Мои вопросы:

1. С Dynamics CRM, как можно было бы сделать что-то подобное? Управляемые решения?
   Что делать, если пользователь сделал настройки на основе v1 развернутого управляемого решения, могу ли я удалить это решение и установить v2?
2. Как осуществляется контроль изменений?
3. Что вы найдете, это лучшие практики, и ямы падают?

Я очень новичок в мире Dynamics CRM, поэтому ваша помощь очень ценится.

Answer 1

Это очень важная дискуссия, и я не думаю, что это лучший ответ, это будет зависеть от того, что вы хотите и как вы работаете.Я согласен с большинством Рикард сказал, я дам вам некоторые ссылки, которые помогают мне много наладить процесс развития:

1 и 3:

• http://gonzaloruizcrm.blogspot.pt/2012/01/managed-or-unmanaged-solutions-in-crm.html
• http://xrmconsultant.blogspot.pt/2011/11/crm-2011-solutions-problems-best.html
• http://channel9.msdn.com/posts/Merging-CRM-2011-Solutions
• http://www.dynamicscrmtrickbag.com/2011/05/28/dynamics-crm-2011-solutions-part-1/

2:

• http://intovsts.net/2012/12/28/integration-of-dynamics-crm-2011-solutions-with-tfs/
• http://community.dynamics.com/product/crm/crmtechnical/b/crmmusings/archive/2012/05/31/solution-packager-enable-source-control-for-solutions-in-crm-2011.aspx

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

Answer 2

Если вы хотите использовать управляемые или неуправляемые решения, вы можете обсуждать их, чтобы вы не получили ответ «сделайте это», или, вернее, вы получите много «сделайте это», которые будут отличаться.

Мой опыт в том, что лучше использовать неуправляемые решения для систем, которыми вы владеете или поддерживаете, и использовать управляемые решения для продуктов, которые вы продаете. Причина, по которой я думаю, заключается в том, что довольно легко создавать зависимости между решениями, которые делают их трудными, если не невозможными, удалять, а в некоторых случаях даже обновлять.

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

Управление изменениями не реализовано в системе, поэтому все, что вам нужно, должно управляться в другом месте.

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

Надеюсь, это поможет.

Answer 3

1. Просто мое скромное мнение: идти неуправляемым, если вы не разрабатываете самостоятельный продукт, который вы могли бы хотеть, чтобы защитить свою целостность, при установке клиентов/случайными пользователями и т.д. Но если вы разрабатываете/настройку клиента конкретных Я не вижу никаких преимуществ управления. Мой опыт заключается в том, что вы, вероятно, столкнетесь с проблемами зависимости и т. Д., Которые заставят вас сожалеть о выборе управляемых. Итак, только управляйте, если вы планируете продавать изолированный продукт, который вам нужно каким-то образом защитить.