Pull to refresh

Версионинг в .NET проектах и не только

Reading time 3 min
Views 949
В методология изменения версий продукта для меня долгое время оставались непонятные моменты, т.к. слишком много различных способов изменения версии при внесении в продукт изменений. Стратегии с которыми я сталкивался — это использование четырех чисел в номере версии(например 1.5.2.871).

Три первых изменяются всегда вручную, и, обычно не превышают 10, а последняя — вручную или автоматически и означает номер билда. Особенно непонятно для меня было как назначать номера версий компонентам продукта, если в Visual Studio solution и в состав продуктов входит не один исполняемый проект, а несколько проектов (может быть и 10, и больше) различных типов (исполняемые модули и библиотеки).

Для себя я придумал вполне устраивающее меня решение, если интересно,

В частности, в .NET проектах к по умолчанию создается файл AssemblyInfo.cs, в котором по умолчанию присутствует следующий код:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]


Может я с этим не до конца разобрался, но заставить механизм с AssemblyVersion(«1.0.*») работать как то более менее вразумительно у меня не получилось. Внятных описаний в MSDN я также не нашел. Поэтому решил подумать над собственным решением, которое неплохо сейчас у меня работает вместе с Subversion.

При выпуске версий продукта часто бывает нужно вручную изменять три первых цифры версии. Увеличиваем первую цифру (major) — очень существенные изменения, возможно даже переписано ядро либо какие то его части. Вторая цифра (minor) — добавлен новый функционал, возможно сравнительно небольшой. Третья цифра — поправлены баги, плюс небольшие улучшения, добавления функционала. Но для тестирования и идентификации билдов этого мало при работе с тестировщиками. Если постоянно именовать дистрибутив как «MyProductSetup_1.3.7» и отдавать на тестирование, работая с issue tracker — идентифицировать билд в котором проблема проявляется довольно сложно. Т.е инкрементировать нужно и последнюю цифру в номере версии. Делать это вручную при наличии множества проектов в solution при каждой новой сборке — весьма нудная работа.

Потому я решил применить автоматическую сборку с автоматическим инкрементом версий. Здесь опишу без деталей реализации (конечно могу добавить если потребуется), скажу лишь что написал небольшой скрипт для MS Build и MS Build Сommunity Tasks, .NET разработчики с этими инструментами думаю хорошо знакомы.

Итак, текущая версия продукта, из 3 цифр, хранится в SVN в plain текст файле(я храню в XML), и изменяется разработчиками продукта вручную, т.к. за изменением версии продукта обычно следует релиз, release notes, уведомления пользователей, обновление сайта и т.д.

Сборка по шагам, выполняемая скриптом:
1. Делаем SvnCheckout
2. Меняем версии в AssemblyInfo.cs во всех проектах на текущую версию + номер ревизии соответствующей ветки проекта. Например, если текущая версия продукта — 1.3.2, а ревизия SVN ветки проекта MySoundLibrary — 286, выставляем версию в AssemblyInfo 1.3.2.286.
3. Для дистрибутива (у меня это InnoSetup) выставляем версию SVN ветки всего solution (каталога, где хранится файл .sln)
4. Выполняем сборку, именуем полученный .exe(.msi) файл как MyProduct_v_1_3_2_286.exe
5. Коммитим изменения. Важно: ветки всех проектов в solution коммитим по отдельности.

В итоге получаем:
— Билд «одной кнопкой»/запуском файла (можно повесить, например, на CruiseControl.NET)
— Каждый билд дистрибутива отражает состояние SVN репозитория в последней цифре имени файла
— Все компоненты билда(.dll, .exe) отражают cостояние соответствующих SVN веток проекта. Т.е. посмотрев, к примеру, на версию .dll файла можно узнать из какой ревизии он был собран. Также удобно отслеживать изменения: чем больше последняя версия .dll файла, тем активнее он менялся.

Может слишком сумбурно изложил, я старался лишь предложить метод, а не реализацию, надеюсь, что я не изобрел колесо:)
Tags:
Hubs:
-6
Comments 5
Comments Comments 5

Articles