Взгляды Microsoft на продукт

[axm2017]

Так как хочу написать внутреннюю статью по фичам то возник вопрос.
Что привело к появлению данного framework?

На мой взгляд причиной является то что изменилась парадигма axapta как продукта, благодаря влиянию Наделлы: заговорили не о революциях (где начинаем жизнь с чистого листа), а о трансформациях продукта, как понимаю были/есть идеи об OneVersion как единственном продукте, который постоянно трансформируется (не будет привычного в ранней парадигме OneVersion 9 ака OneVersion 12 и тп).

Слышал красивую идею-хотелку от MS ников о том что весь код приложения будет в github и для включения какой то дополнительной функциональности лишь делаешь merge каких то нужных вещей и т.п. Перенос партнерского решения тогда выглядит красиво типа поступили деньги и можешь мержить их ветку.

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

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

[Удвой Покуров]

Взгдяд очень простой - стратегия и тотальная некомпетентность.

Стратегия проста:
* Облака (vendor lock, что бы клиент не убежал)
* Подписка (1 доллар в подписке считается рынком как 7)
* SaaS (как 20!!)
* Сокражение партнерской сети и прямые продажи - а зачем им 30-50% платить когда по "классическим" продкутам партнерам хватает нескольких процентов? Что там партнеры эти делают? Они же вместо лицензий продают свои работы и нас обкрадывают!

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

Цитата:

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

для трансформации нужен механизм отката и т п.

Спасибо, теперь у меня новая подпись.

[fed]

Цитата:

Сообщение от Удвой Покуров

Взгдяд очень простой - стратегия и тотальная некомпетентность.

Стратегия проста:
* Облака (vendor lock, что бы клиент не убежал)
* Подписка (1 доллар в подписке считается рынком как 7)
* SaaS (как 20!!)
* Сокражение партнерской сети и прямые продажи - а зачем им 30-50% платить когда по "классическим" продкутам партнерам хватает нескольких процентов? Что там партнеры эти делают? Они же вместо лицензий продают свои работы и нас обкрадывают!

А стратегии смотри также.

[axm2017]

Цитата:

Сообщение от Удвой Покуров

Взгляд очень простой - стратегия и тотальная некомпетентность.

Мягко говоря это не так про некомпетентность.

Цитата:

Сообщение от Удвой Покуров

Стратегия проста:

Меня интересует техническая сторона. Облака кстати удобная вещь.

Цитата:

Сообщение от Удвой Покуров

Ну и принцип "золотого молотка" - эту систему писали динозавры, "она не такая" и мы сейчас все перепишем на новых модных технологиях. А наскучит - перейдем на другой проект.

Вы не внимательно читали. Сатья - противник такого подхода так, как сам был довольно серьезным программером. И OneVerson как раз результат его переосмысления. И как раз переход к эволюционному процессу и привел к появлению feature management and co

[zhan]

На мой взгляд, появление Feature management в D365 FO обусловлено тем, что система рассматривается как классический облачный сервис/ПО и к ней применяется концепция Continues Delivery (выливающаяся в D365 в концепцию Continues Update со стороны Microsoft).
В качестве аналогии, можно попробовать рассмотреть Azure Portal. Его интерфейс и функциональность постоянно обновляются.
Функции из Preview Features переезжают в список общедоступных, при этом меняется наполнение разделов и интерфейс, причём иногда довольно кардинально.

Есть документация по использованию Feature management в DevOps процессах: https://docs.microsoft.com/en-us/azu...w=azure-devops
Эти принципы, возможно, и легли в основу Feature management в D365 FO.
Если взглянуть на Feature management с точки зрения использования этого подхода в коде, то в руководствах по разработке, например, для Azure Function App, прямо указывается как его реализовывать в коде https://docs.microsoft.com/en-us/azu...nctions-csharp
Для D365 FO подобного руководства вроде бы пока нет.
На Yammer, партнёры запрашивали возможность использования Feature management для своих решений, но вроде бы пока это ещё не реализовано.

P.S. На мой взгляд, текущий процесс выпуска версий D365FO с Preview и General available версиями хорошо укладывается в концепцию по приведённой ниже ссылке:
https://docs.microsoft.com/en-us/azu...out-with-rings
Правда по ощущениям, частенько при выпуске нового релиза, всех клиентов, использующих D365 принудительно, записывают добровольцами в «канарейки».