управление релизами Subversion с TeamCity

Question

В настоящее время мы используем Subversion для управления релизами и помечаем все наши релизы (как для QA, так и для наших производственных серверов).Тем не менее, мы хотели бы создать один каталог Release, отражающий наш новейший выпуск.Таким образом, мы можем использовать TeamCity всегда из одной и той же папки для непрерывных сборок.Кроме того, если кто-то должен будет быстро исправить ошибку в рабочей среде, он случайно не попадет в неправильную ветку.

Например, ниже приведена наша текущая структура с добавленной папкой 'release'.Будет ли простой способ перемещать помеченную ветку в 'release' каждый раз, или даже если 'release' будет ссылкой на новейшую версию release_ *?

Уточнение

Вот пример того, как в настоящее время работает наш процесс сборки / выпуска:

• Сегодня я выпускаю версию нашего веб-приложения для QA после успешной сборки TeamCity.Это.При этом я разветвляю / маркирую его
• Завтра, разработчики продолжают делать обновления в стволе.Они не будут отправлены в QA до следующего выпуска QA
• В среду наша команда QA уведомляет нас, что обнаружила ошибку.Мы исправляем ошибку в ветви QA, объединяем изменения обратно в транк и возвращаем обновленную ветку QA обратно в QA.ПРОБЛЕМА № 1: TeamCity больше не работает для нас, так как мы находимся в # 'd QA ветке
• В пятницу QA одобряет релиз для производства, поэтому мы публикуем и разветвляем / тегим
• В понедельник клиент звонит с проблемой, требующей небольшого изменения в производстве.Мы вносим изменения в ветку релиза и возвращаемся к стволу.ВОПРОС № 2: Еще раз, мы вносим изменения без помощи TeamCity

Answer 1

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

Я использую TeamCity как средство определения пути и номера ревизии для извлечения из SVN. Это достаточно просто определить во время выполнения сборки, и любой выпуск в производство всегда выполняется с осторожностью (т. Е. Тщательно проверяйте путь и ревизию). В худшем случае, если вы все испортили, вы всегда можете перезапустить сборку с измененными параметрами.

Вы действительно не хотите в конечном итоге вносить изменения в код непосредственно в папку «Releases» - это то, для чего предназначена магистраль, если она является основной разработкой или ветвями, если вам пришлось настраивать более раннюю версию. Это своего рода избиение SVN к тому, чтобы сделать что-то, что не является его основной силой! С этой точки зрения вы можете найти некоторые советы в 10 заповедей хорошего управления исходным кодом полезных.

Answer 2

Вы можете использовать свойство svn:external, чтобы иметь папку с именем Release Point для другого тега. См. svn: external .

svn propset svn:externals 'release http://my_repo/tags/latest_tag' .

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

Answer 3

Для каждого проекта у нас есть папка Latest, которая содержит, ну, в общем, самую последнюю версию (обычно только двоичные файлы).

Это чрезвычайно полезно для непрерывной интеграции, хотя мы должны использовать собственные сценарии MSBuild дляДля этого, например, выполните удаление содержимого Svn, а затем скопируйте его в папку «Последние».

Answer 4

Вы можете легко написать этот сценарий, чтобы после завершения сборки вы могли скопировать файл или содержимое папки в папку выпуска. Вы даже можете удалить содержимое папки релиза перед этим. Так что да, поскольку ветка или тег в svn - это операция копирования, вы можете легко это сделать.