Уходя в несколько более позитивную тематику. Я тоже как запасной вариант думаю по поводу разработки в стиле Copy-on-Write. То есть - при необходимости внесения более или менее заметных изменений в любой стандартный объект, он тупо копируется, копируются объекты ссылающиеся на него и тд и тп, до тех пор пока мы, грубо говоря, не дойдем до пункта меню.
Я думал над схемой, при которой мы вначале внедрения добавляем весь стандартный микрософтовский код в репозиторий TFS, а потом заводим branch. (или как оно там в TFS называется?). В рамках этого бранча мы создаем вторые копии меняемых объектов и переименовываем их. А после того как Microsoft выпустит очередной хотфикс, мы просто коммитим их изменения в основную ветку, а потом мерджим изменения в нашу клиентскую ветку. Единственный вопрос, который у меня есть по этой схеме - а поддерживает TFS переименование объектов в бранче ? То есть - будет они понимать что мой файл с классом ABCReqCalc это на самом деле бранч файла ReqCalc? Просто в такой схеме еще можно будет как-то внедряться. Если же TFS таких вещей не позволяет, прогнозирую что микрософт конечно сможет легко обновлять свои классы, но клиент об этом не узнает. Стандартные микрософтовские объекты будут легко и регулярно обновлятся, но реальная бизнес-логика будет жить совершенно независимо от них. И партнер будет заниматься ручным мерджингом ТОЛЬКО если клиент наткнулся на конкретную ошибку, которая заведомо исправлена в последних обновлениях.
Также вангую что те клиенты, которые решаться установить сразу несколько вертикальных решений, будут с интересом наблюдать эдак три-четыре копии форм заказов или закупок. Интересно что микрософт будет делать в таких ситуациях...
Последний раз редактировалось fed; 19.04.2017 в 09:35.
|