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

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

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

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

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

Примечание. Есть несколько связанных вопросов по stackoverflow, но я не вижу ничего, что касалось бы этого аспекта цикла развертывания и управления выпуском (см. release-management-in-svn, manage-your-project-life-cycle и лучший способ управления изменениями).


person Shane    schedule 03.11.2009    source источник


Ответы (2)


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

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

Мы также используем JIRA, и здесь сложно ошибиться. Вы можете заставить JIRA следить за сообщениями фиксации Subversion для таких вещей, как «Fixed PROJECT-11», и он автоматически закроет соответствующий элемент JIRA. Оттуда вы можете создавать заметки о выпуске.

person Jason Punyon    schedule 03.11.2009

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

person rahul hajela    schedule 26.03.2018