AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 26.08.2019, 07:19   #1  
Pandasama is offline
Pandasama
Участник
 
134 / 32 (2) +++
Регистрация: 11.08.2014
Адрес: Барнаул
организация инфраструктуры разработки в D365FO
Товарищи, кто активно разрабатывает в D365FO, а расскажите, как у вас построена инфраструктура разработки.
Как я понял из описаний на docs.microsoft.com и около, предполагается примерно следующее:
-для каждого разработчика отдельная DEV-среда
-связываем их все через какой-нибудь VSTS
-имеем TEST-среду (а туда как обновления разработанные разработчиками ставим - через тот же VSTS? или уже пакетами?)
-имеем несколько отдельных DEV-TEST сред, с версией кода/метаданных аналогичных TEST, которые смотря на базу TESTа позволяют нам его дебажить, не мешая тамошним пользователям (как описано здесь - https://docs.microsoft.com/en-us/dyn...ario-debugdiag)

Какие-то ещё хитрости и тонкости?

Может быть эта тема уже на форуме обсуждалась? ткните тогда носом, пожалуйста
Старый 02.09.2019, 14:25   #2  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
77 / 175 (6) ++++++
Регистрация: 25.01.2007
Адрес: Kyiv
?
Цитата:
Сообщение от Pandasama Посмотреть сообщение
-имеем несколько отдельных DEV-TEST сред, с версией кода/метаданных аналогичных TEST, которые смотря на базу TESTа позволяют нам его дебажить, не мешая тамошним пользователям (как описано здесь - https://docs.microsoft.com/en-us/dyn...ario-debugdiag)
Не советую на начальном этапе это применять - есть угроза запутаться самому.

Простая схема
  • один ДЕВ - одна VM (где угодно, хоть в Azure, хоть в виде VHD VM у себя на ноуте)
  • VSTS (Azure DevOps) - если программистов больше одного
  • один TEST

Посложнее
  • один ДЕВ - одна VM (где угодно, хоть в Azure, хоть в виде VHD VM у себя на ноуте)
  • VSTS (Azure DevOps)
  • BUILD server
  • один TEST

Еще сложнее
  • один ДЕВ - одна VM (где угодно, хоть в Azure, хоть в виде VHD VM у себя на ноуте)
  • VSTS (Azure DevOps)
  • BUILD server
  • один TEST
  • один UAT (тоже тестовый сервер)

И еще сложнее, когда версии кода разные для TEST и UAT
  • один ДЕВ - одна VM (где угодно, хоть в Azure, хоть в виде VHD VM у себя на ноуте)
  • VSTS (Azure DevOps) - две ветки (branch) DEV и MAIN
  • BUILD server - билдить два раза - один раз для DEV, второй раз для MAIN
  • один TEST - код из ветки DEV
  • один UAT - код из ветки MAIN

Еще сложнее, когда программистов много и не хочется чтобы кто-то зачекинил код, который поломает билд - просто будет ошибка компиляции
  • один ДЕВ - одна VM (где угодно, хоть в Azure, хоть в виде VHD VM у себя на ноуте)
  • VSTS (Azure DevOps) - две ветки (branch) DEV и MAIN
  • BUILD server - билдить два раза - один раз для DEV, второй раз для MAIN
  • на этом же сервере делаем CI (Continuous Integration) Build Definition как клон с обычных, но дизейблим все шаги после Code Build и включаем триггер на каждый чекин
  • один TEST - код из ветки DEV
  • один UAT - код из ветки MAIN

Для разных проектов - разные настройки и разная сложность инфраструктуры для разработки. Для некоторых решения надо просто дорасти самому проекту.
За это сообщение автора поблагодарили: EVGL (10), trud (5), fed (5), Ivanhoe (5), sukhanchik (7), Vadik (1), wojzeh (1), raz (5).
Старый 02.09.2019, 17:55   #3  
imir is offline
imir
Участник
 
131 / 98 (4) ++++
Регистрация: 28.05.2010
Применительно к локальным развертываниям. У МС есть некая топология Sandbox, которая сетапится, аналогично проду https://docs.microsoft.com/en-us/dyn...e-requirements
Минимум на 7 виртуалок. Это типа UAT, и туда же можно шедулить через LCS установку обновлений и тестировать их. Кто-то может сказать - стоит-ли овчика выделки или можно заменить ее одной виртуалкой OneBox?
Старый 02.09.2019, 18:06   #4  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
77 / 175 (6) ++++++
Регистрация: 25.01.2007
Адрес: Kyiv
Цитата:
Сообщение от imir Посмотреть сообщение
Применительно к локальным развертываниям. У МС есть некая топология Sandbox, которая сетапится, аналогично проду https://docs.microsoft.com/en-us/dyn...e-requirements
Минимум на 7 виртуалок. Это типа UAT, и туда же можно шедулить через LCS установку обновлений и тестировать их. Кто-то может сказать - стоит-ли овчика выделки или можно заменить ее одной виртуалкой OneBox?
Это который D365FFO LBD/on-prem ?

только там не 7 виртуалок, а чутка больше.
но в этом инстансе недоступен Visual Studio и дебаггер.

И на установку всего этого надо угрохать пару недель жизни.

У нас на всех проектах используются Tier1 (oneBox) VM

Даже для проекта с LBD/on-prem
И только перед деплоем на ПРОД у нас есть специальный инстанс LBD/on-prem для проверки деплоя и финальной проверки функциональности.
Старый 02.09.2019, 18:12   #5  
imir is offline
imir
Участник
 
131 / 98 (4) ++++
Регистрация: 28.05.2010
>>есть специальный инстанс LBD/on-prem

Да, вот этот инстанс для проверки, именно на on-prem - собирать и сетапить рядом с продом второй инсталляцией по сути, на 7= виртуалках? Или же есть опция так же заменить его на OneBox..
Старый 02.09.2019, 18:21   #6  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
77 / 175 (6) ++++++
Регистрация: 25.01.2007
Адрес: Kyiv
Цитата:
Сообщение от imir Посмотреть сообщение
>>есть специальный инстанс LBD/on-prem

Да, вот этот инстанс для проверки, именно на on-prem - собирать и сетапить рядом с продом второй инсталляцией по сути, на 7= виртуалках? Или же есть опция так же заменить его на OneBox..
Для LBD/on-prem проектов
должно быть
  • один ДЕВ - одна VM (где угодно, хоть в Azure, хоть в виде VHD VM у себя на ноуте)
  • VSTS (Azure DevOps) - две ветки (branch) DEV и MAIN
  • BUILD server - билдить два раза - один раз для DEV, второй раз для MAIN
  • один TEST - код из ветки DEV, лучше чтобы он был в облаке
  • один UAT - код из ветки MAIN, лучше чтобы он был в облаке
  • один on-Prem/LBD Sandbox/QA - сервер для проверки как деплоится код на on-prem
  • один on-Prem/LBD PROD - собственно главный сервер, точнее более 13 серверов
Старый 03.09.2019, 09:32   #7  
online
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,504 / 4772 (165) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от vmoskalenko Посмотреть сообщение

И еще сложнее, когда версии кода разные для TEST и UAT
  • один ДЕВ - одна VM (где угодно, хоть в Azure, хоть в виде VHD VM у себя на ноуте)
  • VSTS (Azure DevOps) - две ветки (branch) DEV и MAIN
  • BUILD server - билдить два раза - один раз для DEV, второй раз для MAIN
  • один TEST - код из ветки DEV
  • один UAT - код из ветки MAIN
А по какой технологии вы изменения между двумя ветками переносите ? Можно конкретные файлы мерджить, можно вроде бы (сам не пробовал) переносить набор changeset'ов. Мы просто над этой схемой думаем, но сами пока не применяли...
Старый 03.09.2019, 09:55   #8  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
77 / 175 (6) ++++++
Регистрация: 25.01.2007
Адрес: Kyiv
Цитата:
Сообщение от fed Посмотреть сообщение
А по какой технологии вы изменения между двумя ветками переносите ? Можно конкретные файлы мерджить, можно вроде бы (сам не пробовал) переносить набор changeset'ов. Мы просто над этой схемой думаем, но сами пока не применяли...
Ченджсеты. Удобно. Ты видишь список ченджсетов, которые еще не перенесены в MAIN. Выбираешь один или несколько и мерджишь. Потом чекинишь мердж в MAIN. А потом этот ченджсет пропадает из первого списка.

Удобно из-за того, что после мерджа, этот ченджсет пропадает из списка DEV --> MAIN. Можно даже отчеты строить, чем отличается DEV от MAIN с точки зрения DevOps (VSTS).

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

Можно мерджить несколько ченджсетов подряд. Вобщем вам Visual Studio сам скажет что нельзя одновременно мерджить.

Для некоторых сложных проектов мы можем использовать три ветки:
  • DEV - для девелоперов и первого тестирования
  • MAIN - тестирование
  • RELEASE - в продакшн
процесс тот же самый. Цель - улучшить качество и разделить код.
Ветки можно добавлять по мере необходимости.

Еще полезняшка - это добавить правила чтобы девелопер заполнял комментарий и номер Work Item из DevOps (VSTS) всегда. Обязательное поле.
После этого, будет видно, в самом DevOps Work Item что он был включен в билд такой-то. Еще можно будет собрать создание автоматического Release Notes по каждой из веток.
За это сообщение автора поблагодарили: fed (2).
Старый 03.09.2019, 15:14   #9  
imir is offline
imir
Участник
 
131 / 98 (4) ++++
Регистрация: 28.05.2010
Есть еще галка, которая выглядит полезной - Enable multiple check-out, которую если снять - нельзя будет одновременно двум людям менять один и тот же объект. По идее это должно привести к отсутствию конфликтов при check-in. Кто-нибудь пользовался?
Старый 03.09.2019, 16:00   #10  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
77 / 175 (6) ++++++
Регистрация: 25.01.2007
Адрес: Kyiv
Цитата:
Сообщение от imir Посмотреть сообщение
Есть еще галка, которая выглядит полезной - Enable multiple check-out, которую если снять - нельзя будет одновременно двум людям менять один и тот же объект. По идее это должно привести к отсутствию конфликтов при check-in. Кто-нибудь пользовался?
Не работает.

Подробности тут https://developercommunity.visualstu...t-allowed.html

Надо смириться с тем что придётся резолвить конфликты в коде.
Это кстати, одна из причин установки CI на Build Server. Тогда если ты и чекинишь что-то устаревшее и тебе приходится разрешать конфликт кода, тогда ты уверен что твой код будет компилиться.

И тут появляется первое правило для Девелопера - Рабочий день начинается с Get Latest.
Второе правило - Не держи долго задачу в разработке. Если есть что чекинить и это не поломает что-то другое - зачекинь. Нажми кнопку Save для своего кода.
Старый 03.09.2019, 16:18   #11  
imir is offline
imir
Участник
 
131 / 98 (4) ++++
Регистрация: 28.05.2010
Вроде как работает, если все вокспейсы сделают серверными и публичными. Меняется в свойствах вокспейса, кнопка Advanced. А если очень хочется таки извлечь и потом мержить - меняешь тип у своего на локальный (по-умолчанию) и извлекаешь, видимо поэтому написали, что не является ошибкой.
Старый 03.09.2019, 19:18   #12  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
77 / 175 (6) ++++++
Регистрация: 25.01.2007
Адрес: Kyiv
Цитата:
Сообщение от imir Посмотреть сообщение
Вроде как работает, если все вокспейсы сделают серверными и публичными. Меняется в свойствах вокспейса, кнопка Advanced. А если очень хочется таки извлечь и потом мержить - меняешь тип у своего на локальный (по-умолчанию) и извлекаешь, видимо поэтому написали, что не является ошибкой.
И самый каверзный вопрос, А зачем?

Зачем так делать? Только потому что без этого TFS/VSTS в AX 2012 не работал?
Ну так теперь работает. Работает и без этого костыля.
Еще причины есть?

Я так делал в 2015 году для AX7, когда она в бете была. Помогало при редактировании таблиц. А вот с лейблами - была полная засада.
После этого не включал ни разу.
Теги
d365 for operations, d365fo

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
sertandev: How to receive D365FO push notifications using Azure Notification Hubs Blog bot DAX Blogs 0 04.07.2019 18:11
sertandev: How to integrate D365FO with Microsoft Flow using the new Business Events Blog bot DAX Blogs 0 23.05.2019 16:11
erconsult: Copy-paste with keyboard script 2: from Excel to D365FO Blog bot DAX Blogs 0 03.08.2018 11:12
kurthatlevik: D365FO – Some nice excel tricks Blog bot DAX Blogs 0 02.06.2018 00:13
D365FO: Организация разработки - слияние модификаций fed DAX: Программирование 23 30.05.2018 12:32
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 19:55.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.