Configuration Management For Microsoft CRM

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

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

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

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

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

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

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

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

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

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

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

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