организация инфраструктуры разработки в D365FO

[Pandasama]

Товарищи, кто активно разрабатывает в D365FO, а расскажите, как у вас построена инфраструктура разработки.
Как я понял из описаний на docs.microsoft.com и около, предполагается примерно следующее:
-для каждого разработчика отдельная DEV-среда
-связываем их все через какой-нибудь VSTS
-имеем TEST-среду (а туда как обновления разработанные разработчиками ставим - через тот же VSTS? или уже пакетами?)
-имеем несколько отдельных DEV-TEST сред, с версией кода/метаданных аналогичных TEST, которые смотря на базу TESTа позволяют нам его дебажить, не мешая тамошним пользователям (как описано здесь - https://docs.microsoft.com/en-us/dyn...ario-debugdiag)

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

Может быть эта тема уже на форуме обсуждалась? ткните тогда носом, пожалуйста

[vmoskalenko]

Цитата:

Сообщение от 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

Для разных проектов - разные настройки и разная сложность инфраструктуры для разработки. Для некоторых решения надо просто дорасти самому проекту.

[imir]

Применительно к локальным развертываниям. У МС есть некая топология Sandbox, которая сетапится, аналогично проду https://docs.microsoft.com/en-us/dyn...e-requirements
Минимум на 7 виртуалок. Это типа UAT, и туда же можно шедулить через LCS установку обновлений и тестировать их. Кто-то может сказать - стоит-ли овчика выделки или можно заменить ее одной виртуалкой OneBox?

[vmoskalenko]

Цитата:

Сообщение от 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 для проверки деплоя и финальной проверки функциональности.

[imir]

>>есть специальный инстанс LBD/on-prem

Да, вот этот инстанс для проверки, именно на on-prem - собирать и сетапить рядом с продом второй инсталляцией по сути, на 7= виртуалках? Или же есть опция так же заменить его на OneBox..

[vmoskalenko]

Цитата:

Сообщение от 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 серверов

[fed]

Цитата:

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

И еще сложнее, когда версии кода разные для TEST и UAT

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

А по какой технологии вы изменения между двумя ветками переносите ? Можно конкретные файлы мерджить, можно вроде бы (сам не пробовал) переносить набор changeset'ов. Мы просто над этой схемой думаем, но сами пока не применяли...

[vmoskalenko]

Цитата:

Сообщение от 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 по каждой из веток.

[imir]

Есть еще галка, которая выглядит полезной - Enable multiple check-out, которую если снять - нельзя будет одновременно двум людям менять один и тот же объект. По идее это должно привести к отсутствию конфликтов при check-in. Кто-нибудь пользовался?

[vmoskalenko]

Цитата:

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

Есть еще галка, которая выглядит полезной - Enable multiple check-out, которую если снять - нельзя будет одновременно двум людям менять один и тот же объект. По идее это должно привести к отсутствию конфликтов при check-in. Кто-нибудь пользовался?

Не работает.

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

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

И тут появляется первое правило для Девелопера - Рабочий день начинается с Get Latest.
Второе правило - Не держи долго задачу в разработке. Если есть что чекинить и это не поломает что-то другое - зачекинь. Нажми кнопку Save для своего кода.

[imir]

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

[vmoskalenko]

Цитата:

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

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

И самый каверзный вопрос, А зачем?

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

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