Первые впечатления от программирования в D365FO

[sukhanchik]

Отвечу за себя (я не связан с EVGL)
Новизна подходов - безусловно отнимает кучу времени, но это временные трудности.
Тиражированием во все среды может заниматься как и раньше один человек, просто это по времени физически дольше (создал package, залил его в библиотеку активов на LCS, разлил его по средам, нажал в каждой среде кнопку выход после заливки (0,5 часа-1 час ожидания; в момент заливки среды находятся в нерабочем состоянии)). Если на целевой среде есть студия, то процесс заливки без package занимает пару минут с учетом билда и синхронизации (система на время билда будет в нерабочем состоянии, после завершения синхронизации - оборвет все сессии, т.о. с т.з. пользователя система чуток повисит, сбросит сессию и продолжит работу).

Архитектура решения усложнена только тем, что надо ставить ссылки на те или иные модели, которые используются в коде. Захотели использовать финаналитики - добавили ссылку на модель. Валюту - ссылку на модель и т.д. Это мелочи, но их не было раньше, когда все объекты системы были доступны при компиляции сразу без явного добавления каких-нибудь ссылок.

Требования к железу... вопрос условный, т.к. скорость клиента после АХ2012 явно выросла. Скорость БД - на демо-данных визуально незаметна.

Требования к организации работ не стали более высокими. Они просто стали другими по сравнению с АХ2009 и ниже. Ну т.е. к АХ2012 новые требования может и были озвучены, но... можно было работать в условиях старых требований.
Т.е. тут теперь как - у каждого разработчика должна быть своя виртуалка, иначе вместе они физически не смогут работать. Как следствие должна быть версия для сборки и тестирования слитого кода и как следствие должна быть система контроля версий и синхронизации кода между виртуалками разработчиков. При этом вопрос аналогичной синхронизации БД не решен (хотя понятно, что разрабатывать на демо-данных толком не получится).

Раз встает вопрос выделении каждому разработчику своей виртуалки - значит сразу возникает вопрос о выделении времени на ее создание. Штатная виртуалка, которую можно выкачать на локал (и которую готовит МС) требует ее обновления каждые кажется 40 дней (у винды заканчивается демо-режим) и имеет стандартный код и демо-данные. Т.о. после ее выкачивания потребуется ее подключить к системе контроля версий, синхронизировать модели и обновить БД. И так делать регулярно из-за ограничений по времени работы. При этом эта виртуалка будет иметь ограничения - она не будет видна снаружи и соответственно тестировать подключения снаружи на ней будет нельзя. Это коснется проверок веб-сервисов, entity и мобильного приложения.

Как вариант - можно развернуть виртуалку в облаке. Тогда на нее нужно будет только иногда накатывать свежую копию БД и один раз синхронизировать ее с системой контроля версий (все остальное будет работать). Но облако стоит денег.

Т.е. если так рассуждать - в АХ2012 и ранее вход в АХ нечасто осуществлялся через веб-портал, да и портал мог иметь внутренний адрес. Многие использовали Windows-клиента, которому для подключения не требовался внешний URL-адрес АОСа. В D365FO версия стала облачной и эти проблемы всплыли естественным образом. В версии On premise вполне вероятно, что облачные проблемы уйдут, но тогда уйдут и облачные преимущества.

Ключевые потери времени при программировании в D365FO (по сравнению с AX2009) которые я вижу сейчас:
1. Тестирование. Билд+синхронизация+запуск браузера и вход систему. Не засекал точное время, но секунд 30 если не минуту ждать приходится. Раньше это было мгновенно. Даже инкрементная сборка CILа в 2012 не сильно увеличила времени. Более того - полный билд в D365FO у меня длится порядка 1,5 часа против 20 минут сборки CILа в 2012. Это сопоставимо с глобальной компиляцией в AX2009 / 2012, но в них запуск билда не мешал работе системы.
2. Отладка. Установка точек останова + Загрузка отладочных символов. Все, кто отлаживался в клиенте АХ 2009 / 2012 - никто с этим не сталкивался и никто не ждал загрузки отладочных символов, которая может занять и несколько минут. Мало того - они еще не все могут подгрузиться. Кто программировал (отлаживался) в студии для АХ 2012 уже столкнулся с отладочными символами в АХ 2012. Так вот в ней загрузка всех символов была практически мгновенной по сравнению с D365FO. Возможно потому что кода было меньше
3. Невозможность быстрого запуска кода из студии без предварительного билда. Ну т.е. раньше можно было при дизайне формы быстро ее открыть, посмотреть - криво ли накидал поля или нет, поправить и снова открыть. Сейчас такого сделать нельзя. Предпросмотр формы есть на этапе дизайна и это помогает в поиске нужного контрола на форме, но он не покрывает функциональность открытия формы и просмотра окончательного ее внешнего вида. Это в первую очередь относится к своим формам, т.к. про расширения я скажу в следующем пункте.
4. Расширения (extensions). Относительно форм появился процесс поиска "в каком расширении добавлена эта кнопка на форме". Этого процесса раньше не было, а сейчас большей частью процесс поиска делается эмпирическим путем, что отнимает время. Также нет никакого средства посмотреть на дизайн результирующей формы, после того, как на нее наложатся все расширения, если не считать средством билд+запуск системы (п.1) В формах код расположен как раньше, а вот в расширениях код отделен от дизайна и появляется процесс поиска класса, который бы обрабатывал это расширение или форму.
5. В алгоритмах к времени поиска нужного места, куда нужно вставить код добавилось время на продумывание и реализацию способа вставки кода. Все расширения и Event handler-ы вызываются в случайном порядке (имеется в виду, подписанные на одно событие, либо расширяющие один объект) и нужно написать код так, чтобы он не конфликтовал с другими расширениями / обработчиками.
6. Права доступа теперь требуют синхронизации и применяются только после синхронизации БД и синхронизации индексов (не помню как это в 2012 было, может также, но в 2009 точно такого не было). Т.е. если наложить уникальный индекс на данные, на которые он не накладывается, то помимо ошибок синхронизации мы получим невозможность корректировки прав доступа. Учитывая, что со времени 2012 разработкой прав доступа занимается разработчик, разрабатывая привилегии с указанным уровнем доступа - то при сборке кода, если в данных не наложился какой-то индекс (возникла ошибка), то и изменения в правах не применятся. Т.о. добавляется время на содержание синхронизации без ошибок.
7. Рестарт IIS-а и Batch чаще требуется, чем раньше АОСа при разработке. Правда выполняется на порядок быстрее

В общем все это влияет на скорость разработки (пусть местами и незначительно, но при большом количестве незначительного увеличения времени в сумме время увеличивается заметно) и поэтому отсюда такой коэффициент по времени

[imir]

Подскажите кто уже сталкивался еще такой момент TFS, а то прям кушать не могу. Или может есть где почитать - как переносить модифы с дева на тест и сборку, при этом очищая их от чужого кода? Раньше я при импорте XPO на тест - тащил только свое, а чужое не тащил, для этого были развитые средствА в форме сравнения, стрелочки, драг-друп всякий. Как теперь перенести модифу, не затаскивая чужое? Как такое получается при выделенных-то средах? Например, я добавил код в объект A и Вася добавил код в объект A. Васина модифа НЕ идет в тест, а моя идет. Куски Васиного кода в объекте A просто не компильнутся на тесте, потому что там нет остальных частей его модифы, т.е. я не могу просто сделать check in в TFS, порадоваться, что нет конфликтов и спать спокойно.

[belugin]

Цитата:

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

A просто не компильнутся на тесте, потому что там нет остальных частей его модифы, т.е. я не могу просто сделать check in в TFS, порадоваться, что нет конфликтов и спать спокойно.

Я не работал с TFS, но по идее это должно делаться командой merge.

[imir]

Есть такая команда, по сути копирует нечто в другой бранч. Попробовал сейчас как это выглядит - проблемы
1) что мержить - проект лежит в отдельной папке Projects и содержит только ссылки на AOT, объекты - раскиданы по пакам в Metadata
2) При мерже чего-либо, TFS предупреждает, что если будут конфликты - он меня попросит их решить, но конфликтов не будет, с точки зрения tfs

[belugin]

Цитата:

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

Есть такая команда, по сути копирует нечто в другой бранч. Попробовал сейчас как это выглядит - проблемы
1) что мержить - проект лежит в отдельной папке Projects и содержит только ссылки на AOT, объекты - раскиданы по пакам в Metadata

Надо мерджить changeset который содержит ваши изменения.

Цитата:

2) При мерже чего-либо, TFS предупреждает, что если будут конфликты - он меня попросит их решить, но конфликтов не будет, с точки зрения tfs

Почему?

[imir]

changeset, точно, но вот у меня например на маленьком проектике их родилось 20 штук, каждый содержит только изменения, т.е. я должен их накатывать последовательно каждый раз.. да еще в правильном историческом порядке, иначе будет каша. Видел партнерские надстройки, для 2009-й, которые позволяли выбрать автоматом все changeset, связанные с проектом DAX, это было интегрировано в среду разработки dax правда.
Конфликтов не будет, потому что я тащу модифу, в которой куча хвостов от других модиф, кторые тащить не надо, но TFS об этом ничего не ведает, для него это просто файл

[trud]

Цитата:

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

Например, я добавил код в объект A и Вася добавил код в объект A. Васина модифа НЕ идет в тест, а моя идет.

так нельзя теперь. т.е. об этом нужно было заботится заранее, разрабатывая например в разных branch(погуглите branching strategies)

переносить да, командой merge

[trud]

Цитата:

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

Надо мерджить changeset который содержит ваши изменения.

Нет такого понятия TFVC - "changeset который содержит ваши изменения"
TFVC работает с файлами, а не изменениями(в этом отличие от GIT). в GIT да, это можно, но AX не поддерживает GIT

т.е. changeset в TFVC - это просто набор файлов, которые в общем случае могли и меняться другими разработчиками

[belugin]

Цитата:

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

Нет такого понятия TFVC - "changeset который содержит ваши изменения"
TFVC работает с файлами, а не изменениями(в этом отличие от GIT). в GIT да, это можно, но AX не поддерживает GIT

т.е. changeset в TFVC - это просто набор файлов, которые в общем случае могли и меняться другими разработчиками

А вот это что значит?

https://docs.microsoft.com/en-us/vst...mand?view=vsts


/version

For a selective merge, this option specifies the range that should be merged into the destination. For a catch-up merge, this parameter specifies the version before which all un-merged changes should be merged.

For a selective merge, the version range denotes the beginning and end points of the set of changes to be merged. For example, if you attempt to merge version 4~6, the changesets 4, 5, and 6 are merged.

[imir]

Цитата:

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

так нельзя теперь. т.е. об этом нужно было заботится заранее, разрабатывая например в разных branch(погуглите branching strategies)

переносить да, командой merge

Интересно.. у меня своя дев-машина и у Васи своя дев-машина. Теперь еще получается, что у меня свой бранч и у Васи свой. Тогда как мне синхронизировать свою машину по метаданным с остальной командой?

[belugin]

Прочитайте про branching strategies

[trud]

Цитата:

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

For a selective merge, the version range denotes the beginning and end points of the set of changes to be merged. For example, if you attempt to merge version 4~6, the changesets 4, 5, and 6 are merged.

[/I]

Я так понимаю соберутся файлы из этих ченжсетов и скопируются в ветку, ну т..е это не будут изменения, а просто файлы. именно поэтому и нет команды rebase(которая вызывает бурные дискуссии в GIT)

[imir]

Читаю пока, но много партнеров, пилящих свои обертки вокруг TFS вряд ли не читали. Я кстати тоже пытался писать свою пару лет назад.
Попробовал выбрать merge changset - получил окно с полным списком changeset, в формате: номер, дата, разработчик. Без привязки к конкретному проекту, без фильтрации, сортировки и вообще понимания что это.. только мультиселект для отметки нужных мне. А когда этих changeset там будет не 40 с моих трех модиф, а 100500..
Это к вопросу мержа, а вопрос конфликтов - окей, я в своем бранче, ноя в своем бранче параллельно пилю несколько модиф, или одну пилю, три тестируются.. нужно отделить свое же добро от своего же.

[trud]

Цитата:

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

Это к вопросу мержа, а вопрос конфликтов - окей, я в своем бранче, ноя в своем бранче параллельно пилю несколько модиф, или одну пилю, три тестируются.. нужно отделить свое же добро от своего же.

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

[belugin]

Цитата:

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

Я так понимаю соберутся файлы из этих ченжсетов и скопируются в ветку, ну т..е это не будут изменения, а просто файлы. именно поэтому и нет команды rebase(которая вызывает бурные дискуссии в GIT)

А я так понимаю что должны наложиться именно изменения. Мне было бы очень странно если такой функциональности не было бы в какой-то VCS.

Rebase это не то. Тут скорее merge

[belugin]

Цитата:

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

Это к вопросу мержа, а вопрос конфликтов - окей, я в своем бранче, ноя в своем бранче параллельно пилю несколько модиф, или одну пилю, три тестируются.. нужно отделить свое же добро от своего же.

Feature isolation

Feature isolation is a special derivation of the development isolation, allowing you to branch one or more feature branches from main, as shown, or from your dev branches.

Feature Isolation branching strategy

When you need to work on a particular feature, it might be a good idea to create a feature branch.

Keep the lifetime of feature work and the associated feature branch short-lived. Forward integrate (FI) changes from the parent branch frequently. Reverse integrate (RI) back to the parent only when some agreed team criteria, for example definition of done, is met. Rollback of features on main can be costly and may reset testing.

[imir]

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

[imir]

Цитата:

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

When you need to work on a particular feature, it might be a good idea to create a feature branch.

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

[imir]

Цитата:

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

For a selective merge, the version range denotes the beginning and end points of the set of changes to be merged. For example, if you attempt to merge version 4~6, the changesets 4, 5, and 6 are merged.

[/I]

Проверил - выбрал merge - changeset. Получил окно с наборами - мультислект есть, а выбрать два и более не дает - серится кнопка Next.
А если мержить только последний, то и получишь только последний, т.е. классик какой-то из целого проекта.

[trud]

Цитата:

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

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

Автотестов наверное тоже не писали
А тем не менее для клиента это скорее плохо чем хорошо