Configuration Management For Microsoft CRM

[Савран Роман]

Коллеги, добрый день

Занимаюсь поддержкой и разработкой Майкрософт ЦРМ для нескольких клиентов + есть небольшая команда разработчиков/кастомизаторов.

Сейчас передо мной стоит задача ускорить и оптимизировать их процесс работы. На данный момент уже почти дописал плагин к Visual Studio, который позволяет:
1. Регистрировать в CRM плагины открытого в студии проекта по хмл файлу конфигурации
2. Копировать pdb файлы в папку CRM, делать iisreset, подключаться к w3p (включая режим удаленной отладки), чтобы отлаживать плагин по одной кнопке.
3. После ребилда проекта автоматически обновлять плагин в CRM
Если кто хочет - пишите, я после того как закончу над ним работу (ориентировочно 30 июня), могу дать погонять. Может у кого-то есть еще какие-то пожелания насчет его работы?

Сейчас еще зародилась идея проекта по отслеживанию настроек, которые делаются в системе для простого их переноса. Идея достаточно простая. Есть какое-то требование заказчика, например номер 1275. Мы фиксируем это требование и логируем все изменения метаданных и данных, которые делает программист Петя когда разрабатывает это требование (при помощи плагинов). Потом при необходимости переноса воспроизводим эти изменения в нужном CRM.

Это правда будет работать только в том идеальном случае, когда среда разработки изначально совпадает с тестовой средой и продакшн .

В общем суть этой темы в следующем - как повысить производительность разработок и настроек для Mircosoft CRM, какие для этого есть утилиты и подходы, или идеи.

[Савран Роман]

С логгированием изменений настроек немного наломался. Оказывается в CRM нельзя зарегистрировать плагин на изменение метаданных (список событий метаданных http://msdn.microsoft.com/en-us/library/cc151148.aspx). У кого-то есть опыт написания утилит отслеживания изменений в метаданных ? Например, добавления атрибутов, сущностей и т.д.

Пока приходит в голову только вешать триггеры на таблицы метаданных CRM, но мне этот метод не очень нравится

[Артем Enot Грунин]

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

[slivka_83]

Цитата:

Сообщение от Савран Роман

С логгированием изменений настроек немного наломался. Оказывается в CRM нельзя зарегистрировать плагин на изменение метаданных (список событий метаданных http://msdn.microsoft.com/en-us/library/cc151148.aspx). У кого-то есть опыт написания утилит отслеживания изменений в метаданных ? Например, добавления атрибутов, сущностей и т.д.

Пока приходит в голову только вешать триггеры на таблицы метаданных CRM, но мне этот метод не очень нравится

Цитата:

SELECT*FROMsys.objectsWHEREDATEDIFF(D,modify_date,GETDATE())< 10

[Савран Роман]

Спасибо за ответы, задача в принципе состоит из нескольких вещей:
1. Уменьшить время от озвучивания клиентом задачи, то воплощения ее в ЦРМ.
2. Уменьшить количество людских ошибок при переносе настроек.
3. Уменьшить трудозатраты на разработку требований.
4. Сохранить качество на высоком уровне.

В рамках разработки можно выгружать кастомизации и крепить их к проекту, ложить в свн. Это оправданно и нужно.

Но часто задачи по поддержке достаточно просты, например добавить поле на форму. Для этого выгружать настройки из црм, крепить к проекту и коммитить в свн достаточно долго. Накладные расходы по времени больше времени решения задачи, поэтому хотелось бы иметь автоматизированный тул, который сам бы отслеживал и версионировал изменения в ЦРМ в привязке к задаче клиента. В рамках проекта или поддержки.

Как это обычно выглядит у нас:
1. Клиент говорит "У меня поменялся бизнес-процесс. Вместо кнопки А должна быть кнопка Б и делать она должна не Г а Д".
2. Консультант формулирует и передает задачу разработчику.
3. Разработчик делает задачу
4. Консультант проверяет на тесте (если есть необходимость подключается еще кто-то протестировать полноценно, если задача сложная)
5. Разработчик переносит на продакт

У некоторых клиентов переносится несколько требований сразу, формируется т.к. называемый релиз. Зависит от размера клиента, некоторым нормальные процессы разработки и поддержки не под силу .

Самые узкие места процесса обычно в таком случае - качественное ведение списка задач и перенос настроек. Так, как, например разработчик мог сделать задачу и уже сесть за следующую, пока консультант протестирует. Потом ему надо возвращаться к задаче и вспоминать что же он там сделал и что ему надо перенести. А так, например, при подтверждении консультантом, разработку мог бы перенести и специалист поддержки, не обладающий, например, такой квалификацией как программист.

Кроме этого не хотелось бы, например, перекидывать все настройки, а только дельту и иметь возможность отката настроек - возврата системы в предидущее состояние до релиза.

У меня была также идея написать приложение в котором программист перед разработкой фиксировал какие объекты системы (сущности, плагины и т.д.) заденет разработка, они бекапились и после разработки формировался бы пакет для переноса на другой ЦРМ. Такая схема, правда, не исключает людских ошибок. Многое из этого уже есть в ЦРМ 2011, к сожалению далеко не все клиенты пока перешли, а если быть точнее - только 1 перешел, 1 планирует, остальные пока не собираются и может и не соберутся.

Вопрос следующий - кто какой процесс использует для разработки и как вы управляете средами (Разработки\Тестирования\Рабочая среда) и как и когда (по требованию клиента, после разработки и т.д.) переносите настройки между ними?

[Савран Роман]

Цитата:

Сообщение от slivka_83

Я имел ввиду также изменение представлений, например, или кастомизаций форм. Оба эти изменения не меняют структуру таблиц базы CRM, а меняют данные таблиц метаданных CRM.

[Konstantin Katsovich]

Цитата:

Сообщение от Савран Роман

Я имел ввиду также изменение представлений, например, или кастомизаций форм. Оба эти изменения не меняют структуру таблиц базы CRM, а меняют данные таблиц метаданных CRM.

А чем плох plugin message "Publish" либо "PublishAll"?