|
18.05.2018, 14:42 | #1 |
Участник
|
ну новизна в том что они не просто существуют где-то там "на ноутбуке разработчика в виде архива rar", а существуют в текущей версии, описаны и готовы к установке-использованию по одному клику на приложении клиента
|
|
18.05.2018, 15:32 | #2 |
Участник
|
Вот про установку по кнопке я пропустил - когда это появилось? Можно ссылочку какую-нибудь?
__________________
Ivanhoe as is.. |
|
18.05.2018, 17:06 | #3 |
Участник
|
ну это часть процесса валидации. Curation meeting шаг 4
т.е. решение должно развертываться, данные должны загрузаться и пользователь должен делать транзакции Deploy a standard Microsoft Dynamics 365 for Finance and Operations environment that has partner code that is based on the package contents (Code, Binaries, and Config). https://docs.microsoft.com/en-us/dyn...-lcs-solutions |
|
18.05.2018, 18:00 | #4 |
Участник
|
Стоп, стоп. Вы про документы про валидацию или про реальный кейс? Мы как партнер должны были показать MS как деплоится наше решение (аналогично было и на предыдущих версиях), но при чем тут клиент? В самом магазине клиент не может нажать "купить и установить".
__________________
Ivanhoe as is.. |
|
20.05.2018, 03:51 | #5 |
Участник
|
В самом нет, не может, процесс немного другой
У решения может быть несколько партнеров, вы смотрите краткое описание связываетесь с партнерами для демо-доп. вопросов. Если дошли до того что хочется "поработать" в решении, партнер через LCS(опять же в 1 клик) может установить вам Package на одно из ваших приложений(не отдавая при этом исходный код и ограничив лицензию по времени действия - это тоже кстати было большое ограничение в АХ2012, что технически это не реализовывалось) Необходимые данные опять же можно подгрузить через LCS |
|
18.05.2018, 22:15 | #6 |
Участник
|
И еще про одну штуку забыл, в 7 версии же у нас есть частичная перекомпиляция - можно добавить в проект несколько узлов АОТ, скомпилировать только их и запустить - и получить приложение с изменениями (работает для разработческого сценария). В каких-то правда случаях подглюкивает, но по скорости работы больше чем перекомпиляция целиком (я не очень понял как это работает).
И еще скорее всего начиная с 8.0 партнерам и клентам, надо будет не менять Applictaion Suite а расширять его сравнительно маленькими модулями. Т.е. хотсваппинг бы помог (не надо перезапускать), но непонятно, как его делать, с учетом того, что можно, например, передать, объект по ссылке между формами - что он должен в одной форме быть одной структуры а в другой - другой? |
|
20.05.2018, 01:26 | #7 |
Banned
|
Чуть не по теме но тот Blazor который интерпретирует Mono
комбинирует разметку с C# кодом что собственно и заставило меня смотреть на PHP как оригинал. С пониманием того что концепции .NET оказались дутыми. Цитата:
В Blazor компонент это .NET класс, который вы можете написать напрямую (то есть как C# класс) или, что более принято, в виде страницы разметки Razor (.cshtml файл).
Появившийся примерно в 2010 году Razor это синтаксис для комбинирования разметки с C# кодом. |
|
20.05.2018, 01:46 | #8 |
Участник
|
Цитата:
Цитата:
С пониманием того что концепции .NET оказались дутыми.
|
|
21.05.2018, 11:26 | #9 |
Administrator
|
Отвечу за себя (я не связан с 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 чаще требуется, чем раньше АОСа при разработке. Правда выполняется на порядок быстрее В общем все это влияет на скорость разработки (пусть местами и незначительно, но при большом количестве незначительного увеличения времени в сумме время увеличивается заметно) и поэтому отсюда такой коэффициент по времени
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 21.05.2018 в 11:35. |
|
|
За это сообщение автора поблагодарили: belugin (5), AlexeyS (5), Logger (3), EVGL (20), Stitch_MS (5), AP-1055D (4). |
21.05.2018, 11:47 | #10 |
Участник
|
Подскажите кто уже сталкивался еще такой момент TFS, а то прям кушать не могу. Или может есть где почитать - как переносить модифы с дева на тест и сборку, при этом очищая их от чужого кода? Раньше я при импорте XPO на тест - тащил только свое, а чужое не тащил, для этого были развитые средствА в форме сравнения, стрелочки, драг-друп всякий. Как теперь перенести модифу, не затаскивая чужое? Как такое получается при выделенных-то средах? Например, я добавил код в объект A и Вася добавил код в объект A. Васина модифа НЕ идет в тест, а моя идет. Куски Васиного кода в объекте A просто не компильнутся на тесте, потому что там нет остальных частей его модифы, т.е. я не могу просто сделать check in в TFS, порадоваться, что нет конфликтов и спать спокойно.
|
|
21.05.2018, 12:36 | #11 |
Участник
|
Цитата:
|
|
21.05.2018, 13:08 | #12 |
Участник
|
|
|
21.05.2018, 13:29 | #13 |
Участник
|
Интересно.. у меня своя дев-машина и у Васи своя дев-машина. Теперь еще получается, что у меня свой бранч и у Васи свой. Тогда как мне синхронизировать свою машину по метаданным с остальной командой?
|
|
21.05.2018, 12:51 | #14 |
Участник
|
Есть такая команда, по сути копирует нечто в другой бранч. Попробовал сейчас как это выглядит - проблемы
1) что мержить - проект лежит в отдельной папке Projects и содержит только ссылки на AOT, объекты - раскиданы по пакам в Metadata 2) При мерже чего-либо, TFS предупреждает, что если будут конфликты - он меня попросит их решить, но конфликтов не будет, с точки зрения tfs |
|
21.05.2018, 12:56 | #15 |
Участник
|
Цитата:
Цитата:
2) При мерже чего-либо, TFS предупреждает, что если будут конфликты - он меня попросит их решить, но конфликтов не будет, с точки зрения tfs
|
|
21.05.2018, 13:15 | #16 |
Участник
|
Нет такого понятия TFVC - "changeset который содержит ваши изменения"
TFVC работает с файлами, а не изменениями(в этом отличие от GIT). в GIT да, это можно, но AX не поддерживает GIT т.е. changeset в TFVC - это просто набор файлов, которые в общем случае могли и меняться другими разработчиками |
|
21.05.2018, 13:29 | #17 |
Участник
|
Цитата:
Сообщение от 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. |
|
21.05.2018, 13:40 | #18 |
Участник
|
Я так понимаю соберутся файлы из этих ченжсетов и скопируются в ветку, ну т..е это не будут изменения, а просто файлы. именно поэтому и нет команды rebase(которая вызывает бурные дискуссии в GIT)
Последний раз редактировалось trud; 21.05.2018 в 13:42. |
|
21.05.2018, 14:16 | #19 |
Участник
|
Цитата:
А если мержить только последний, то и получишь только последний, т.е. классик какой-то из целого проекта. |
|
21.05.2018, 13:05 | #20 |
Участник
|
changeset, точно, но вот у меня например на маленьком проектике их родилось 20 штук, каждый содержит только изменения, т.е. я должен их накатывать последовательно каждый раз.. да еще в правильном историческом порядке, иначе будет каша. Видел партнерские надстройки, для 2009-й, которые позволяли выбрать автоматом все changeset, связанные с проектом DAX, это было интегрировано в среду разработки dax правда.
Конфликтов не будет, потому что я тащу модифу, в которой куча хвостов от других модиф, кторые тащить не надо, но TFS об этом ничего не ведает, для него это просто файл |
|
Теги |
ax7, dynamics 365 for operations, x++ |
|
|