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

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