Замораживание кода в SVN - Управление сборкой

Question

Есть ли лучший способ реализовать замораживание кода в SVN, чем просить всех разработчиков не регистрировать новый код?
У нас работает CruiseControl, который автоматически развертывает последнюю сборку в среде. Поэтому, если приходит новый код, сборка, которая была сделана доступной ранее, изменится на последнюю. Я хочу, чтобы развернутая сборка происходила из определенной ветви / тега, чтобы любые новые проверки кода не влияли на развернутую сборку. Только когда я добавлю тег / ветку в следующий раз, новый код должен быть снова развернут. Как мы можем достичь этого?

Answer 1

Использование встроенной функции SVN ветвления . Следующая ссылка показывает вам все подробности о том, как выполнить переход (вы также можете использовать теги, если хотите): http://svnbook.red -bean.com / ru / 1.1 / ch04.html

Answer 2

Соглашение Subversion о том, о чем вы говорите, - это создание тега. Конечно, тег ничем не отличается от ветви в том, что это просто копия определенной строки разработки с определенной ревизией (обычно ... это сложные теги). Тем не менее, наилучшей практикой в ​​Subversion является то, что теги создаются один раз и НИКОГДА не фиксируются - это только снимки.

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

Answer 3

Используйте стабильную ветку и Subversion> = 1.5 (сервер, формат репозитория и клиенты).

Сделайте ветку из Trunk и обозначьте ее как вашу стабильную ветку. Запретите разработчикам вносить изменения в эту ветку, в идеале используйте файл authz с любыми доступными вам разрешениями.

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

Имейте часы круиз-контроля, постройте и разверните из назначенной стабильной ветви вместо ствола.

Когда наступит время для развертывания нового программного обеспечения, используйте функцию слияния Subversion для объединения в ветку из магистрали. Всегда объединяйте таким образом, только из транка, и отслеживание слияния (только версия 1.5 и выше) гарантирует, что вы можете выбрать и включить только те изменения, которые вы хотите из транка, исключая то, что вам не нужно. Это также позволит вам визуально проверить, какие именно ревизии включены в текущий выпуск, а какие исключены.

После объединения и проверки результатов фиксация кода приведет к публикации круиз-контроля, поэтому публикация происходит только в контролируемых точках.

Если вам необходимо выполнить откат к предыдущей версии, создайте тег из требуемой ревизии стабильной ветви и временно укажите Круиз-контроль на нее вместо стабильной ветви, когда вы разобрались с проблемами в стабильной ветви, затем вы можете снова выполнить развертывание из стабильной ветви вместо тега.

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

Не занимайтесь разработкой стабильной ветви, за исключением устранения конфликтов слияния, или объединяйте изменения из других мест, кроме транка, - очень трудно будет точно сказать, что развернуто.

Answer 4

Конечно, есть и блокировка в механизме доступа - например, настройка файла authz.

Answer 5

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

#!/bin/sh
exit 1

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