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

[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

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