Внедрение AX 2012 R3 в 2018-м году на новых российских проектах - за и против

[sukhanchik]

Как раз-таки из п.3 следует не быстрая, а медленная реакция ИТ на изменения. Экстеншены не могут ускорить разработку - они ее только замедляют, потому что решая вопрос "какие изменения внести" приходится дополнительно решать вопрос "как внести эти изменения".

Пример 1 (примеры приводятся технические, без привязки к бизнес-процессам и обсуждения, что идеологически этот пример не будет применен в жизни).
Заявка на закупку. Хочу в строках разрешить лукап номенклатуры (он изначально доступен только при создании строки, а я хочу ее выбирать и после создания строки). Но... на поле таблицы строк заявки стоит AllowEdit = No (AllowEditOnCreate=Yes).
Без экстеншенов достаточно было изменить только свойство на поле таблицы. (пример условный, предполагаем, что остальной код работает корректно). Ориентировочно, с учетом всех бюрократий (записать часы, внести изменения в багтрекер, задеплоить, протестировать и т.д.) будем считать, что это 0,5 часа.
С экстеншенами приходится делать edit-метод на гриде формы (т.е. делать экстеншн формы), плюс писать код по обработке этого edit-метода (lookup, modified, jumpref). Учитывая, что мы не можем влезать в код обработки этого поля, то нам нужно еще писать код, который бы запрещал / разрешал редактирование этого поля, например, когда запущен Workflow. Ну и если какая-то еще логика была на этом поле - ее также надо "перетянуть".
Т.о., с учетом всех бюрократий - на это можно потратить часа 4 (учтем, что с увеличением сложности разработки пропорционально увеличивается и время тестирования, т.о. усложнение разработки допустим в 2 раза увеличивает общее время решения задачи минимум раза в 4).

Цифры условные, если кто-то считает, что 4 - это много, то всяко думаю понятно, что эта работа сильно больше, чем просто поменять свойство на поле.

В моем случае соотношение получилось 1:8 - т.е. в 8 раз дольше занимает решение задачи через экстеншены по сравнению с оверлеингом.

Пример 2. Хочу добавить раскраску строк на форме. Пусть это бантик, но ... опять-таки в контексте гибкости изменений - это нормальное желание. Система технически не предоставляет возможности это сделать без оверлеинга либо дублирования формы. Дублирование формы чревато тем, что если к ней были сделаны экстеншены, то их нужно будет склеивать в нашу новую форму. Что влечет за собой дополнительные расходы. Ну и надо понимать, что дублирование формы предполагает встраивание ее в меню, во всякие иные вызовы и т.д. Опять-таки, при несложном критерии раскраски - с оверлеингом или своей формой задача решается за 0,5-1 час (со всей бюрократией). Дополнительные работы с учетом тестирования и прочей бюрократией опять могут дотянуть до 4-х часов.

Все вышесказанное не означает, что экстеншены плохие. У них есть самый главный плюс - их легко устанавливать в систему, если они готовые и корректно написаны. Корректно - это означает, что они не зависят от дополнительных экстеншенов, которые надо дополнительно устанавливать, либо все можно установить одним пакетом для данного конкретного клиента. В мире продаж - это корректно называть расширения / экстеншены, а в мире разработки они называются моделями.
Т.е. если к примеру представить себе, что вышло какое-то новое веяние - новое законодательство или новая мода (например, интеграция с соцсетями), то готовый корректный экстеншен можно загрузить из какого-нибудь магазина расширений и вуаля - "осталось" только его настроить.

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

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

[trud]

Цитата:

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

Пример 1
Заявка на закупку. Хочу в строках разрешить лукап номенклатуры

Что-то мне кажется вы сделали допущение что у вас в данный момент есть кто-то кто знает как это делать плюс свободен, кроме того опустили момент развертывания(который описан в документе Deploying Customizations Across Microsoft Dynamics AX 2012 Environments
https://technet.microsoft.com/en-us/.../hh292604.aspx )
т.е. на практике это выглядит так(задача пусть та-же)
-посылается запрос партнеру
-прожект менеджер со стороны партнера ищет и выделяет консультанта, выделяет программиста
-задача кодируется-тестируется, обновленная модель высылается клиенту
-клиент выполняет установку модели на тестовое окружение(рекомендованная MS схема ниже, т.е. это минимум полдня работы человека IT), кроме этого на этом этапе могут возникнуть куча ошибок связанных с тем что версия АХ разработчика-партнера отличалась от вашей версии АХ(к примеру вы устанавливали какие-то фиксы от МС или решение другого партнера)


-клиент выделяет пользователей для тестирования всего этого, хорошо если тестировать можно на любой базе, если нужны рабочие данные – это еще Procedure for initializing a staging environment from a production environment – несколько страниц описания
-IT выделяет людей которые согласовывают остановку системы и в нерабочее время выполняют развертывание новой версии, пишут торжественное письмо как все круто обновилось


Ну т.е. в этом модели работы время программиста вообще ничтожно, будет там полчаса или 4. Если сравнить в этом ключе, то возможно D365 будет более прозрачна и быстрее

[KiselevSA]

Цитата:

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

т.е. на практике это выглядит так(задача пусть та-же)

Мне вот интересно, какая часть модификаций соответствует приведенному выше "сферическому коню в вакууме", ну если не считать разработок отдельных модулей или "тяжелых" доработок, затрагивающих большое количество объектов и системных классов?
Я чаще сталкиваюсь с другой схемой: у клиента есть три окружения - dev, test и prod.
На dev делают разработки, на test переносят проектом с отсечением лишнего из смежных доработок с помощью сравнения, а после тестирования, в зависимости от "пристрастий" клиента, перенос на prod проектом или моделью.
Меня еще другой вопрос занимает: в D365 решили проблему с "пропаданием" добавленных в CU DeleteAction, если в таблице внесены изменения на не системных слоях?

[skuull]

Цитата:

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

Мне вот интересно, какая часть модификаций соответствует приведенному выше "сферическому коню в вакууме", ну если не считать разработок отдельных модулей или "тяжелых" доработок, затрагивающих большое количество объектов и системных классов?

Это зависит не от доработок, а от клиента. Следуя этой схеме моделстор можно накатить за 15 мин + синхронизация. Причем в идеале оттестировынный моделстор, что исключает ошибки сведения моделей или xpo. Некоторым клиентам плевать на даунтайм, хоть все выходные развлекайся, а некоторые работают 24/7 и готовы платить за зоопарк лишь бы не было простоя. Видимо вам такие не попадались.

[ax_mct]

Цитата:

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

т.е. на практике это выглядит так(задача пусть та-же)
...
Ну т.е. в этом модели работы время программиста вообще ничтожно, будет там полчаса или 4. Если сравнить в этом ключе, то возможно D365 будет более прозрачна и быстрее

Не согласен. На практике пример 1 c лукапом будет идти как дополнительное пожелание и просто добавиться к чему-то большему. Никто в здравом уме не будет деплойить такое на PROD отдельно. То есть собственной процедуры деплоймента у подобных задач считай что нет.

Если взять AX2012 и AX2009 то затраты на деплоймент очень сравнимы. На моей текущем проекте AX2012 полное развертывание на PROD (5 серверов) занимает у меня 2 часа старым классическим способом через XPO (Это не значит что мы не умеем готовить модели, просто нет нужды). Да и с моделями затраты на деплоймент будут те же что и в AX2009.

Никакой непрозрачности нет, c AX2012 можно деплойить так же прозрачно и быстро как и с AX2009, AX2004.

Не хочешь XPO, а хочешь по модному как в D365O? Team Foundation Server в руки. Для D365O TFS обязателен, а для AX2012 опционален.

Коэффициент стоимости разработки 8 раз видется вполне реалистичным, то что как минимум 4 раза - не вызывает сомнений. Деплоймент же в D365O никак не может быть прозрачней и быстрей чем в AX2012. Так как единственно за счет чего это может быть - TFS, но он прекрасно предназначен и для AX2012.

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

[bio_unit]

Цитата:

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

Пример 2. Хочу добавить раскраску строк на форме. Пусть это бантик, но ... опять-таки в контексте гибкости изменений - это нормальное желание. Система технически не предоставляет возможности это сделать без оверлеинга либо дублирования формы. Дублирование формы чревато тем, что если к ней были сделаны экстеншены, то их нужно будет склеивать в нашу новую форму. Что влечет за собой дополнительные расходы. Ну и надо понимать, что дублирование формы предполагает встраивание ее в меню, во всякие иные вызовы и т.д. Опять-таки, при несложном критерии раскраски - с оверлеингом или своей формой задача решается за 0,5-1 час (со всей бюрократией). Дополнительные работы с учетом тестирования и прочей бюрократией опять могут дотянуть до 4-х часов.

Вас услышали:
Platform Update 15: https://docs.microsoft.com/en-us/dyn...form-update-15

Ability to color grid rows without overlayering via FormDataSource OnDisplayOptionInitialize event
The ability to color grid rows without overlayering is now possible via the OnDisplayOptionInitialize event on FormDataSource.