Как правильно управлять выпуском с помощью SVN?

Question

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

Моя новая фирма намного меньше, и я заинтересован в поиске недорогого эквивалента с низким уровнем обслуживания, даже если это просто означает прямое взаимодействие с SVN.В частности, я регулярно обнаруживаю, что коммиты в конце игры нарушают нашу сборку, и становится очень трудно разобраться, что мы можем включить.(Что касается управления SVN, я склонен предпочитать идею тегов ветвям, потому что это требует меньше предусмотрительности, но я рад убедиться в обратном.)

Что люди используют, чтобы помечать коммиты для выпуска и выполнять последующее развертывание?Существуют ли какие-либо хорошие решения с открытым исходным кодом для управления циклом выпуска, которые позволяют просматривать SVN из веб-браузера и помечать проблемы / коммиты для выпуска?Лучшее, что я видел до сих пор, это Джира, но это выглядит как очень большой инструмент (сложно ли его настраивать / обслуживать?).Apache Foundation хорошо использует Jira для этой цели (см., например, дорожная карта Mahout).

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

Примечание:Есть несколько слегка связанных вопросов по stackoverflow, но я не вижу ничего, что охватывало бы этот аспект цикла развертывания и управления выпусками (см. управление выпусками в svn, управляйте жизненным циклом вашего проекта, и наилучший способ справиться с управлением изменениями).

Answer 1

Если вы обнаруживаете сбои при сборке слишком поздно в игре, чтобы эффективно их исправить, вам определенно следует воспользоваться CI train, прежде чем начинать беспокоиться о процессе выпуска.Возложение ответственности на разработчиков за целостность сборки - гораздо более простой процесс, когда каждый раз, когда кто-то проверяет что-то, что выводит из строя pooch, отправляются электронные письма.Превратите это в игру;Тот, кто сломает сборку, должен присматривать за ней до следующего раза, когда она будет сломана.

Запуск с CruiseControl (я использовал CC.NET) не так ли сложно с subversion (я получил нас от отсутствия процесса сборки, о котором можно говорить, до полностью автоматизированной сборки и развертывания с CC.NET и НАнт примерно через месяц, чередуясь, конечно, с другими обязанностями).

Мы также используем JIRA, и здесь трудно ошибиться.Вы можете попросить JIRA просмотреть сообщения о фиксации subversion для таких вещей, как "Исправленный ПРОЕКТ-11", и он автоматически закроет соответствующий элемент JIRA.Оттуда вы можете создать свои заметки о выпуске.

Answer 2

Вы исследовали график ревизий Tortoise SVN?Если вы пометите каждый выпуск (что, как указывали другие, не предполагает копирования файлов ни на сервер, ни на рабочую станцию), то вы сможете увидеть все редакции в хронологическом порядке, с тегами, указывающими на фактические выпуски.Вы можете различать версии и / или магистрали, выделив две интересующие вас редакции и выбрав diff из контекстного меню