Re: Политика смены версий и межпроектных ссылок
От: Щербатов Евгений  
Дата: 03.11.07 12:32
Оценка: 33 (4)
Здравствуйте, Igor Trofimov, Вы писали:

iT>Интересно, у кого как принято работать с версиями сборок .net, если есть множество друг от друга зависящих проектов?

iT>Часть из них разрабатывается обычно независимо, а часть — может активно развиваться "параллельно".
iT>Кто как меняет номер версии? Когда, каким образом?
iT>Интересует, конечно, в первую очередь, не смена major.minor, а смена младших номеров.
iT>Меняются ли версии в течение дня? Или раз в день, во время ночной сборки?
iT>Или при каждой сборке не сервере continuous integration? Или все — только ручками?
iT>Ну в общем, тут есть много вариантов, интересно, кто как делает.

У нас сделано так. Мы разрабатываем большую систему, в которой несколько больших solutions. Ссылки между проектами внутри solution делаются, как project-reference, а между solution — как assembly-reference. В каждом из проектов есть AssemblyInfo.cs (мы на С# пишем), в котором версия всегда 1.0.0.0. И эту версию никто из девелоперов не имеет права менять. С этой целью в системе контроля версий на все AssemblyInfo.cs у нас висят эксклюзивные блокировки наложенные администратором. Поэтому, если девелоперу и нужно что-то изменить в AssemblyInfo.cs, то он это сделает, но только у себя на компьютере, побалуется и успокоится — зачекинить свои изменения не сможет.

Компоновкой продукта занимается специальный билдовый сервер. Перед непосредственной компоновкой сервер анализирует каждый проект на предмет изменений в нем с момента последней компоновки. Проверка заключается в том, что сервер сравнивает хеши (по MD5) всех файлов проекта и сам проектный файл (prj). Если изменения все же были, то сервер сам наращивает разряд Build в AssemblyInfo.cs, а также проходится по всем проектным файлам, в которых есть ссылки на измененный проект и также корректирует в них ссылки. Все это делается для каждого проекта, затем идет компоновка. После компоновки все измененные cs и prj файлы чекинятся в систему контроля версий, НО в специальную отдельную метку, создаваемую самим билдовым сервером для нового построенного билда. Таким образом, если снять исходные коды построенного продукта из метки, то там будут проставлены все версии, как положено. Если же снять исходные коды из того view, с которым работают сами девелоперы, то там всегда будет 1.0.0.0 — все счастливы и никто друг другу не мешает.

Результаты последней операции расстановки версий (номера, хеши) билдовый сервер в конце операции тоже чекинит в систему контроля версий, чтобы при новом билде воспользоваться ими.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.