Непрерывная интеграция - это определенно правильный путь - любой CI (даже минималистские командные файлы) лучше, чем ничего - но он будет только настолько хорош, насколько применимы ваши политики. Поскольку ваши файлы на самом деле не являются «бинарными» или «распространяемыми», для маркировки выпуска может потребоваться лишь пометить репозиторий или даже просто спрятать номер ревизии Subversion где-нибудь. Важная политика, которая вам нужна, заключается в том, что любой выпуск может быть восстановлен в любое время, когда вам это нужно, чтобы вы могли сравнить текущий и предыдущий выпуски или вернуться к более старому выпуску, если что-то пойдет не так. Не беспокойтесь о «накладных расходах» на создание тегов в SVN - это очень эффективно.
Скрипт выпуска, который делает тег subversion звучит нормально. Реализация CI (я бы порекомендовал CruiseControl, поскольку он идеально подходит для гетерогенной работы, хотя гетерогенность требует немного больше накладных расходов на конфигурацию) - это здорово, поскольку вы можете автоматически запускать процесс при проверке Subversion и запускать автоматические тесты, определяющие, хорош ли он достаточно пометить или нет.
Я бы точно не развернул автоматическое развертывание на сервере релизов. «Зона подготовки» (назовите ее «ночная сборка», «бета-тест» и т. Д.) Была бы лучше. Пусть ваши пользователи откажутся от этого, прежде чем вы решите, что это достаточно хорошо для развертывания на производственных серверах. И, если у вас есть политика, позволяющая выполнять откат к более ранней версии, вы уменьшаете вероятность неудачного развертывания.
Автоматическая проверка на производственных серверах - это единственная «хакерская» часть - автоматическое развертывание с проверкой, тестированием, тегами и бета-тестами достаточно простое. Однако при развертывании производства не должно быть простой кнопки.