Лучший способ объединить Git с .NET при управлении версиями

В настоящее время я работаю над проектом (только я), и я уже знаю, как обращаться с версиями на нем. Я использую классический <major>.<minor>.<build or patch>.

Проблема заключается в том, что я хочу иметь теги в некоторых моих коммитах, указывающих на соответствующие версии, но я не хочу делать это вручную.

Теперь я сейчас делаю:

Если я собираюсь выпустить v0.2.13, я изменяю AssemblyInfo.cs и устанавливаю эту версию
Зафиксировать изменения на Git
Добавить тег v0.2.13 (вручную) на Git
Постройте проект
Создайте файл .zip (не все время) и назовите его как ProjectName v0.2.13

Я делаю это неправильно?

Я мог бы легко создать script, чтобы сделать последний шаг автоматически, но мне интересно, есть ли хорошая практика автоматизации другой части?

Ответ 1

У меня есть сборка script в MSBuild, которая автоматически извлекает фиксацию git в данный момент, а затем добавляет такой атрибут во время сборки к сборке:

[assembly: AssemblyInformationalVersion("0.2.13+e3a6f2c1")]
[assembly: AssemblyVersion("0.2")]
[assembly: AssemblyFileVersion("0.2.13")]

Численная часть версии происходит из файла version.txt, который читает моя сборка script.

В версии сборки отсутствует 3-й октет, поскольку он позволяет избежать необходимости пересылать требования перенаправления при добавлении номера сборки. AssemblyFileVersion включает в себя все данные, разрешенные этим атрибутом, а AssemblyInformationVersion может быть любой строкой, которую вы хотите, поэтому используйте семантическое управление версиями, чтобы включить фиксацию git id позволяет точно указать, какая версия исходного кода построила этот проект.

Затем, после успешной сборки, вы можете добавить тег v0.2.13, если хотите. Лично, как только я создаю окончательный выпуск, я увеличиваю файл version.txt так, чтобы все последующие сборки имели следующий более высокий номер версии. Каждая сборка после этого будет иметь это, пока я не отпущу эту версию, пометка фиксации, еще раз увеличит файл version.txt и повторю.

Кстати, строка AssemblyInformationalVersion появляется в свойствах файла из Проводника Windows, поэтому это обеспечивает гарантированный способ перехода от произвольного встроенного двоичного кода к исходному исходному коду. Кроме того, к сожалению, этот подход заставляет csc.exe сообщать AL? предупреждение о сборках, потому что формат семантической версии не соответствует синтаксису x.y.z. Это не значит, что все сломано, и я просто игнорирую предупреждение.

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

Ответ 2

Я использую Makefiles для всего после фиксации.

В зависимости от того, как работает ваша система сборки, вы можете добавить целевой "выпуск", который тегирует текущую ветку и толкает этот тег. Вы также добавили бы цель "пакета", которая зависит от целей "сборки" и "выпуска".

Если это не сработает, просто создайте свой собственный Makefile. Возможно, вам не обязательно будет указывать ваш "Makefile" по-разному.

Ответ 3

Если у вас нет возможности использовать сервер сборки, возможно, это лучший способ сделать это вручную. Тем не менее, если у вас есть время, я настоятельно рекомендую вам создать какой-либо тип сервера сборки. У нас был большой успех с TeamCity. Если у вас есть настройка для отслеживания вашего репозитория, есть способы сделать сборку информации об ассемблере, tagging и развертывание после сборки (для них есть куча возможных ссылок, я рекомендую просто нажать documentation).

Я нашел этот пост очень полезен при настройке нашего управления версиями; вы можете в значительной степени исключить бит NuGet, и он должен иметь некоторую приличную информацию. Что касается настройки TeamCity, просто выполните быстрый поиск "Учебного пособия по установке TeamCity", и у вас должно быть много ресурсов. Удачи!

Ответ 4

Я успешно использовал следующие шаги, чтобы выполнить что-то похожее на:

Нажать новую команду на общий репозиторий git
Сервер TeamCity проверяет код, запускает тесты и строит проект
В случае успеха TeamCity также перемещает/удаляет/файлы пакетов для пакета развертывания
Затем он пересылает почтовый индекс в область развертывания развертывания, где его можно вручную развернуть (это может быть полностью автоматизировано, но наша настройка была странной)

Вы можете использовать привязку после фиксации, чтобы пометить свою ветку и нажать на сервер TeamCity.

Ответ 5

Нант подходит вашим потребностям! Проверьте это: ссылка на NAnt

Он прост в использовании и объединяется с репозиторием git: -)