У нас есть набор связанных продуктов, написанных на VB6, с некоторыми проектами на C # и VB.NET, и весь исходный код хранится в одном репозитории Subversion.
Мы не использовали ветки в Subversion (хотя мы сейчас делаем выпуски тегов), и просто делаем всю разработку в транке, создавая новые выпуски, когда транк достаточно стабилен. Это не дает конца печали, когда мы выпускаем новую версию, с ней обнаруживаются проблемы, и мы уже начали работать над новыми функциями или существенными изменениями в магистрали. В прошлом мы решали эту проблему одним из двух способов, в зависимости от серьезности проблем и от того, насколько стабильной мы считали магистраль:
Спешите стабилизировать транк, исправить проблемы, а затем выпустить обновление обслуживания, основанное на ревизии HEAD, но это имело побочный эффект выпусков, которые исправляли ошибки, но вводили новые проблемы из-за неполных функций или исправления, которые были в стволе.
Заставьте клиентов ждать следующего официального релиза, который обычно составляет несколько месяцев.
Мы хотим изменить нашу политику, чтобы лучше справляться с этой ситуацией. Я думал о создании «ветки обслуживания» в Subversion всякий раз, когда я отмечаю официальный релиз. Затем новая разработка продолжится в транке, и я могу периодически объединять конкретные исправления из транка в ветку обслуживания и создавать выпуск для техобслуживания, когда накопится достаточно исправлений, в то время как мы продолжаем параллельно работать над следующим крупным обновлением. Я знаю, что мы могли бы также иметь более стабильную магистраль и вместо этого создать ветку для новых обновлений, но мне проще держать текущую разработку в магистрали.
Основная проблема заключается в том, что, хотя мы можем легко разветвлять исходный код из тега выпуска и перекомпилировать его, чтобы получить двоичные файлы для этого выпуска, я не уверен, как обрабатывать проекты установки и установки. Мы используем QSetup для создания всех наших программ установки, и сейчас, когда нам нужно изменить проект установки, мы просто редактируем файл проекта на месте (все проекты установки и любые зависимости, которые мы не делаем Скомпилированные сами хранятся на отдельном сервере, и мы всегда компилируем установочные проекты только на этом компьютере). Однако, поскольку мы можем добавлять или удалять файлы в настройке при изменении нашего кода, нет никакой гарантии, что сегодняшние проекты установки будут работать со вчерашним исходным кодом.
Я собирался поместить все проекты QSetup в Subversion, чтобы справиться с этим, но я вижу некоторые проблемы с этим подходом.
Я хочу, чтобы создание программ установки было как можно более автоматизировано, и, по крайней мере, я хочу отдельную машину для сборки, на которой я могу собрать нужный релиз (сначала получая код из Subversion), захватить установку проект для этого выпуска от Subversion, перекомпилируйте настройку, а затем скопируйте настройку в другое место в сети для тестирования качества и возможного выпуска для клиентов.
Однако, когда кому-то нужно изменить проект установки (добавить новую зависимость, которая требуется для транка, или внести другие изменения), возникает проблема. Если они обрабатывают его как исходный файл и проверяют его на своем компьютере, чтобы отредактировать, они не смогут добавлять файлы в проект, если сначала не скопируют файлы, необходимые для добавления на компьютер сборки (поэтому они другим разработчикам), затем скопируйте все остальные зависимости со сборочной машины на свою машину, убедившись, что она соответствует структуре папок точно . Проблема здесь в том, что QSetup использует абсолютные пути для любых файлов, добавленных в проект установки. Однако это означает установку множества зависимостей установки на машины разработки, которые кажутся грязными (и которые могут дестабилизировать среду разработки, если кто-то случайно запустит проект установки на своей машине).
Кроме того, как мы управляем сторонними зависимостями? Например, если текущая ветвь обслуживания использовала MSXML 3.0, а для магистрали теперь требуется MSXML 4.0, мы не сможем вернуться и создать версию обслуживания, если мы уже заменили библиотеку MSXML на компьютере сборки на последнюю версию (при условии, что обе версии имеют одинаковое имя файла). Единственное решение, которое я могу придумать, - это либо поместить все сторонние зависимости в Subversion вместе с исходным кодом, либо убедиться, что мы поместили разные версии библиотеки в отдельные папки (т.е. C:\Setup\Dependencies\MSXML\v3.0 и C:\Setup\Dependencies\MSXML\v4.0). Один способ «лучше» или более распространен, чем другой?
Есть ли лучшие практики для решения этой ситуации? По сути, если мы выпускаем v2.0 нашего программного обеспечения, мы хотим иметь возможность выпускать v2.0.1, v2.0.2 и v.2.0.3, пока мы работаем над v2.1, но весь проект установки / установки и настройки проблема зависимости делает это более сложным, чем типичный ответ «просто создайте ветку в Subversion и перекомпилируйте при необходимости».