организация инфраструктуры разработки в 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

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

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