Реализация процессов разработки - управление версиями и установщики

Question

В моей команде мы создаем сборки для присоединения к расширяемому выпущенному программному обеспечению, созданному и опубликованному в других местах моей компании. Эти сборки часто специфичны для отдельного клиента, хотя некоторые используются повторно. Я хочу ввести в эту среду несколько стандартов - номера версий и установщики.

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

В настоящее время сборки устанавливаются отдельным пользователем, копируя их вручную по правильному пути и выполняя любую необходимую регистрацию. Я хочу заставить людей использовать установочный пакет, чтобы путь и регистрация обрабатывались автоматически.

Я мог бы реализовать первый шаг, заставив людей использовать:

[assembly: AssemblyVersion("1.0.*")]

Но я бы предпочел обновить AssemblyFileVersion, а не AssemblyVersion. Это потому, что я понимаю, что продвижение AssemblyVersion в сочетании с нашей ручной установкой может привести к регистрации нескольких версий сборки. AssemblyFileVersion не обновляется автоматически, и я опасаюсь решения, которое требует от разработчиков установки сторонних инструментов. Если бы у нас был правильный процесс установки, проблема могла бы исчезнуть из нескольких версий.

На втором шаге, если я использую проект установки Visual Studio, то добавление сборки вызывает попытку добавить другие сборки из исходного опубликованного программного обеспечения, что мне не нужно. Я предполагаю, что могу создать это как-то как патч, но я еще не решил это. Конечно, установщику потребуются надежные номера версий, иначе все будет плохо.

Кажется очевидным, что, написав это, мне нужно продвигать обе проблемы одновременно, но я бы действительно предпочел подходить к одному по очереди.

Есть какие-нибудь мысли о том, как лучше решить эти две проблемы?

Answer 1

У меня недостаточно информации, чтобы указать вам решение.Что вы используете для создания приложения и установщиков?Настольный F5 построить?Team Foundation Server?Круиз-контроль?

Что нужно понять:

1) Проекты развертывания Visual Studio suck .Да, я буду придерживаться этого комментария.В вашем случае проблема сканирования зависимостей не устраняется.Даже если вы щелкните правой кнопкой мыши |исключить зависимость, она может сканировать новую зависимость во время сборки.Мы даже написали визуальную студию автоматизации, чтобы открыть проект, щелкните правой кнопкой мыши |исключите все, а затем сохраните его на сборочной машине, чтобы избежать этой проблемы.Поверьте мне, это ужасная дорога, чтобы идти вниз.Даже Microsoft знает, что это отстой, и поэтому его не будет в следующем выпуске Visual Studio.Используйте другие инструменты, такие как установщик Windows XML или InstallShield Limited Edition или Professional.

2) Вы должны обновить AssemblyFileVersion.Это такой основной / основополагающий клиент управления изменениями, и он очень важен для работы обновлений и исправлений установщика Windows.AssemblyVersion может быть изменена по вашему усмотрению и применима только к сценариям Strong Naming и IoC, таким как Prism, где вы пишете правила о том, что составляет допустимый класс для внедрения.

3) 1.0. * Не то, что вам нужно,Вам нужна система, которая увеличивает вашу версию и передает ее в вашу автоматизацию сборки.То, что вы используете, будет зависеть от того, что вы используете для автоматизации сборки.Я использую Team Foundation Server и проект в CodePlex для своей версии.

4) Вы никогда не должны собираться на машине разработчика.Вы всегда должны использовать машину для чистой сборки с автоматическими сценариями, а не F5.

Answer 2

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

Если вы опубликовали программное обеспечение, хорошим примером является загрузчик на клиенте, который вызывает обновления, а затем запускает установщик обновлений.

Основной ответ: у вас есть варианты, в зависимости от того, какие биты вы используете, и должны использовать те, которые соответствуют вашим потребностям.