D365FO: Организация разработки - слияние модификаций

[fed]

Цитата:

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

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

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

sukhanchik: Тема выделена из Создание меток для AX7

[belugin]

После перехода на символьные, а не числовые метки, меточный файл сливается так же легко, как и любой другой файл исходников. Если использовать kdiff3 как merge tool, независимые добавления сливаются вообще полностью автоматически.

[belugin]

Цитата:

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

Наверно, стандартный редактор меток был (есть) слишком тормознутный и/или модальный по отношению к остальной студии.

Сейчас редактор такая же вкладка студии как и все остальные. Ее можно придочить, вынести на дополнительный монитор и т.д.

Упс. Есть два редактора - если открыть меточный файл это вот так. Если вызвать из меню диалог find labels это другое, модальное.

Цитата:

Его нужно было открывать мышкой из меню (шорткат вроде есть, но я его не осилил запомнить, возраст ) вместо alt-tab.

Еще можно Cltr+Q и набрать label.

[belugin]

Цитата:

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

Я хочу интерфейс с WinForms переделать на Electron, отрефакторить код, добавить плагины, добавить создание меток из исходного текста по проекту. Или попробовать встроить в студию. Хотя пока мне нравится, что можно по alt-tab переключаться.

Если хочется встроить в студию, то надо делать UserControl на WPF мне не очень понятны достоинства электрона с учетом того, что разработка не кроссплатформена.

[trud]

Цитата:

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

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

так а где гарантия что кто-то не создаст одинаковые метки для разных текстов(из за излишних сокращений или спец символов типа ?)
Вообще конечно работа с метками это наиболее простой показательный пример в различиях в работе МС и Дамгарда.
т.е. в оригинале каждый аспект работы был продуман(типа несколько языков в одной форме, создание сразу из объекта, отображение в сво-вах именно значения, а не метки).
все же интерестно как они решили тратить на это время, думаю при гораздо скромных бюджетах чем МС

[belugin]

Цитата:

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

так а где гарантия что кто-то не создаст одинаковые метки для разных текстов(из за излишних сокращений или спец символов типа ?)

Вот не знаю. Пока с таким не сталкивался. Наверное тот, кто будет мерджить получит отлуп при компиляции.

[sukhanchik]

Цитата:

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

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

Да, именно так и делаю. Каждому разработчику по своей модели (одна задача - одна-две модели; смена задачи - смена моделей). Каждой модели - свой меточный файлик. Проблем с конфликтами нет.
Единственное, что - могут возникать проблемы разделения кода по моделям - что писать в одной модели, а что в другой. Но в целом - проблемы решаются и даже иногда получается очень удобно (когда некий базовый код удается собрать в одной модели, на которую ссылается несколько моделей)

[skuull]

Цитата:

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

Да, именно так и делаю. Каждому разработчику по своей модели (одна задача - одна-две модели; смена задачи - смена моделей). Каждой модели - свой меточный файлик. Проблем с конфликтами нет.
Единственное, что - могут возникать проблемы разделения кода по моделям - что писать в одной модели, а что в другой. Но в целом - проблемы решаются и даже иногда получается очень удобно (когда некий базовый код удается собрать в одной модели, на которую ссылается несколько моделей)

По одной модели или по одному пакету?

[sukhanchik]

Модели. Пакет (я правильно понимаю, что пакет = deployable package?) в себе может конечно содержать несколько моделей, но только если они не ссылаются друг на друга.

Нет смысла делать единый меточный файл на пакет - все равно файл же в модели создается.

Если модель будет в себе содержать относительно независимую область, то можно будет по моделям делить модификации. Модификаций может быть и несколько на одну модель. Например, все модификации по заявкам на закупки могут быть сделаны в одной модели. А по справочнику клиентов - по другой. И меточные файлы между ними совершенно не обязаны иметь формат вида @ХХХ12345. Пусть у них будут разные файлы.

[AlexSD]

Цитата:

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

Если хочется встроить в студию, то надо делать UserControl на WPF мне не очень понятны достоинства электрона с учетом того, что разработка не кроссплатформена.

Это пока мой учебный проект. Поскольку сама идея простая, можно попробовать использовать различные технологии сразу получив рабочий инструмент. Электроном меня Бирюлин соблазнил. Это не пренос ответственности, просто для истории

Электрон меня заинтересовал с того времени, как я узнал что на нем сделана VS Code, Slack, Postman и т.д. (https://electronjs.org/apps). Капнув его немного оказалось, что я быстрее могу с ним разобраться, чем с WPF.

Upd: т.е., с HTML и Node.js легче разобраться, чем с WPF.

[skuull]

Цитата:

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

Модели. Пакет (я правильно понимаю, что пакет = deployable package?) в себе может конечно содержать несколько моделей, но только если они не ссылаются друг на друга.

Вы уверенны что именно модели ссылаются на модели ? Т.е., по вашему, возможна ситуация когда у меня есть deployable package A с 2мя моделями: АА и АБ, где АА ссылаеться на AppSuite, а АБ - нет ?

[belugin]

Модели ссылаются на пакеты AKA модули

[sukhanchik]

Цитата:

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

Вы уверенны что именно модели ссылаются на модели ? Т.е., по вашему, возможна ситуация когда у меня есть deployable package A с 2мя моделями: АА и АБ, где АА ссылаеться на AppSuite, а АБ - нет ?

Ээээ... Что-то Вы меня смутили )))
Ситуация. Имеем порядка 20 моделей, каждая из которых создавалась, как Create new package (выбирался этот режим в мастере при создании модели).
Эти модели могут ссылаться на разные модели, в т.ч. кто-то может ссылаться на AppSuite, а кто-то нет. Помимо AppSuite есть еще Directory, ContactPerson и еще куча мелких моделей, на которые уж точно не все модели ссылаются.
Кроме стандартных моделей они могут ссылаться друг на друга (циклические ссылки исключены). Т.о. у меня получилось 5 уровней пакетов. 1-й уровень - модели, ссылающиеся на стандартные модели, 2-й уровень - модели, ссылающиеся на стандартные модели и модели 1-го уровня; 3-й уровень - модели ссылающиеся на стандартные модели и модели 1-го и 2-го уровней и т.д. Само собой одна моя модель принадлежит какому-то одному уровню.

Так вот - при апгрейде кода с 7.2 PU10 на 8.0 PU15 была создана в облаке чистая среда (не проапгрейдена, а именно создана с нуля), в которой были только стандартные модели. На нее было последовательно залито 5 deployable package, каждый из которых соответствовал уровню пакета (а в пакете было само собой несколько моделей). Т.о. были залиты все 20 моделей.
Пакет (package) тут вообще ни причем. Ссылки идут на модели. И нельзя заливать пакет, в котором находятся модели, ссылающиеся друг на друга. А вот по уровням - пожалуйста. И совершенно без разницы - есть ли в где-то в одной модели ссылка на AppSuite или ее нет

[skuull]

Цитата:

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

Ээээ... Что-то Вы меня смутили )))
Ситуация. Имеем порядка 20 моделей, каждая из которых создавалась, как Create new package

Вот вы и ответили на мой вопрос. Вы создаете 1 пакет на 1 модель. Модели, насколько я понимаю, существуют только в дизайне и потом всё равно все билдится по-пакетно. Т.е. как писал выше belugin пакеты = модули которые ссылаются на что-то. В одном пакете (не deployable, это я не правильно спросил, просто пакете) может быть много моделей которые ни на что не ссылаются, посмотрите на AppSuite пакет, там много моделей.

Зачем я все это спрашиваю ? Просто МС активно на яммере пишет, что если вы не ISV то больше 1 пакета вам не надо. В вашем случае мне интересно что вы выиграли от этого? Ведь пакет с 3го уровня нельзя выдернуть и использовать отдельно без первого и второго уровня. Имея 20 меточных файлов можно попасть в ситуацию когда в каждом из них есть метка "Конь" и если вы решили переименовать ее в "Сфера" то придётся создавать 20 новых меток вместо одной.

Еще появляется сложность из-за того что из нижних пакетов не видно объектов из верхних, т.е. придётся иногда двигать код между ними. Это наверно все хорошо и правильно с точки зрения разделения, модульности и бла-бла, но добавляет сложности без видимого для меня преимущества (если вы не ISV, а просто лабаете моды)

[belugin]

belugin пакеты = модули которые ссылаются на что-то.

Модели из дескрипторов ссылаются на модули. Ну и модули посредством их.

[trud]

Цитата:

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

Еще появляется сложность из-за того что из нижних пакетов не видно объектов из верхних, т.е. придётся иногда двигать код между ними. Это наверно все хорошо и правильно с точки зрения разделения, модульности и бла-бла, но добавляет сложности без видимого для меня преимущества (если вы не ISV, а просто лабаете моды)

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

[sukhanchik]

Цитата:

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

Вот вы и ответили на мой вопрос. Вы создаете 1 пакет на 1 модель. Модели, насколько я понимаю, существуют только в дизайне и потом всё равно все билдится по-пакетно. Т.е. как писал выше belugin пакеты = модули которые ссылаются на что-то. В одном пакете (не deployable, это я не правильно спросил, просто пакете) может быть много моделей которые ни на что не ссылаются, посмотрите на AppSuite пакет, там много моделей.

Все понятно, большое спасибо.

Цитата:

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

Зачем я все это спрашиваю ? Просто МС активно на яммере пишет, что если вы не ISV то больше 1 пакета вам не надо. В вашем случае мне интересно что вы выиграли от этого? Ведь пакет с 3го уровня нельзя выдернуть и использовать отдельно без первого и второго уровня. Имея 20 меточных файлов можно попасть в ситуацию когда в каждом из них есть метка "Конь" и если вы решили переименовать ее в "Сфера" то придётся создавать 20 новых меток вместо одной.

В моем случае все просто. Как начали создавать пакеты, так и дальше продолжили не задумываясь о последствиях. Так что тут искать глубокого смысла не стоит, тем более, что яммер - штука в явном виде не сильно открытая и большими красными буквами в заголовке там не пишут, что требуется всего один пакет - надо быть достаточно активным читателем яммера ) (хотя я его и просматриваю периодически).
Но решение продолжить так работать в моем случае подкрепилось скоростью билда. Я вот смотрю на AppSuite (на папку в PackagesLocalDirectory) и пока не особо вижу большого количества там подпапок, да и dll-ка там получается одна на пакет и достаточно большая (интересно, долго ли она билдится?)


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

Цитата:

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

Еще появляется сложность из-за того что из нижних пакетов не видно объектов из верхних, т.е. придётся иногда двигать код между ними. Это наверно все хорошо и правильно с точки зрения разделения, модульности и бла-бла, но добавляет сложности без видимого для меня преимущества (если вы не ISV, а просто лабаете моды)

Это да, по сути получается как разработка на разных слоях. Но вот если у Вас был опыт разработки в одном пакете и разных моделях - то как сильно увеличилось время билда в таком режиме? В моем понимании - dll-ка должна создаваться одна на пакет, а не на модель в наших с Вами терминах.

У меня все просто - билд достаточно быстрый, т.к. по сути одна модификация=одна модель=один пакет=одна dll. Конечно уже появились "тяжелые" модели, но это скорее исключение, т.к. тоже приходилось пробовать различные варианты для понимания как организовывать разработку.

Из плюсов моего подхода у меня пока выявился один (не считая скорости билда). Возможно есть еще (а также есть минусы), я просто не сравнивал свой подход с каким-либо другим.
Я делал импорт различных данных из Sharepoint и я смог разделить свой код на 2 части. Одну, которая подключается к Sharepoint, авторизуется и получает данные и вторую, которая эти данные обрабатывает. В результате я создал несколько моделей - одну для работы с Sharepoint и другие, которые ссылаются на эту модель (как будто у меня получилось мини-ISV-решение для импорта из Sharepoint).
Билд модели, которая связана с Sharepoint был усложнен наличием дополнительной dll-ки, написанной на C#. А билд моделей-обработчиков ничем не усложнен и выполняется быстро. В результате получилась ситуация "забилдил и забыл", что очень упрощает дальнейшую разработку в сторону Sharepoint-а

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

[skuull]

Кто-нибудь унесите это все в другую тему, а то мы отошли от темы меток. (sukhanchik: Выделено)

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

Пример с SharePoint идеальный для отдельного пакета, т.к. его можно использовать на множестве проектов. Опыт же разделения какстомизаций по моделям у меня отрицательный, т.к. нет ни времени ни бюджета играться в архитектуру. Клиенту нужны простые и кривые моды которые автоматизируют его простые и кривые бизнес процессы. Иногда они настолько неожиданные что о таком и не подумаешь, это заставляет переносить все в один пакет или лепить абстракции там где они не нужны чтобы избавиться от перекрёстных ссылок. Добавляют проблем коллеги которые в модули играться не хотят, а хотят как было в 4ке\9ке\12ке - лепить все в кучу.

[sukhanchik]

Не.. это все понятно. Вопрос не в этом. Я бы тоже хотел лепить все в кучу для экономии времени разработки. Вот разработчику дали задачку - добавить поле на форму. Он должен сбилдить свой проект, чтобы все запустилось. Если он не билдит свой проект, то как он отлаживается? Если он билдит - то как долго? (Ему ж надо весь App Suite перебилдить?)

С хотфиксами ситуация достаточно простая - их необязательно ставить каждые два часа. Вполне достаточно накопить их и оптом (допустим в конце недели) поставить. Ну и организационно добиться того, чтобы их не ставили бесконтрольно. Да и разве Ваши собственные модификации (имеются в виду модификации всей проектной команды) не выходят (выпускаются разработчиком для теста) чаще МСовских? Если уж клиент хочет все в кучу

[skuull]

Так а при чем тут App Suite ? Вы создаете себе свою модель в своем пакете который имеет ссылку на App Suite. Дальше каждый разработчик создает себе по проекту на модификацию в этой моделе\пакете, это проект билдит и синхронизирует когда ему надо. А билд сервер уже билдит ваш пакет создает из него deployable и вы его накатуете когда куда вам надо накатить. VS прекрасно (почти всегда) умеет билдить 1 проект без надобности билдить всю модель.