Разработка выпуска экономичного программного обеспечения (веб-приложений)

Question

Я хочу реорганизовать способ выпуска нашего внутреннего программного обеспечения.Весь код (веб-приложения PHP, некоторые приложения Java и сценарии Perl) проверяется в репозиториях Subversion, но ветвей или тегов нет, все проверяется в магистрали (всего около 1-3 разработчиков на приложение).На производственных серверах Linux программное обеспечение запускается непосредственно из рабочей копии svn (на самом деле там тоже происходит большая часть изменений).

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

Существуют ли какие-либо инструменты, которые могут помочь мне сделать это в такой гетерогенной среде (с точки зрения языка)?Или есть у кого-нибудь идеи, как это сделать правильно?

В противном случае я подумал о написании некоторых сценариев выпуска (оболочки), которые автоматически создают теги Subversion из магистрали, а затем проверяют соответствующий тег на производственных серверах.Но мне это тоже кажется хакерским.

Спасибо,

Хаес.

Answer 1

Непрерывная интеграция, безусловно, лучший вариант: любая CI (даже минималистичные пакетные файлы) лучше, чем ничего, но она будет настолько хороша, насколько хороша ваша политика.Поскольку ваши файлы на самом деле не становятся «двоичными» или «распространяемыми», для маркировки выпуска может потребоваться только пометить репозиторий или даже просто спрятать где-нибудь номер версии Subversion.Важная политика, которая вам нужна, заключается в том, что любой выпуск можно восстановить, когда вам это понадобится, чтобы вы могли сравнить текущий и предыдущий выпуски или вернуться к более старому выпуску, если что-то пойдет не так.Не беспокойтесь о «накладных расходах» на создание тегов в svn — это очень эффективно.

Сценарий выпуска, который использует тег Subversion, звучит нормально.Реализация CI (я бы порекомендовал CruiseControl, поскольку она идеально подходит для гетерогенной работы, хотя гетерогенность требует немного больше затрат на настройку) великолепна, поскольку вы можете автоматически запустить процесс при проверке Subversion и запустить автоматические тесты, которые определят, хорош ли он. достаточно отмечать или нет.

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

Автоматическая проверка на производственных серверах — единственная «хакерская» часть: автоматическая проверка, тестирование, тегирование и бета-развертывание достаточно просты.Однако внедрение в производство не должно быть простой кнопкой.

Answer 2

Используйте теги и ветки;сделайте это частью цикла разработки.Когда вы обновляете ветку «stable-1.0», тестируете изменения и помечаете их «release-1.0.5», вы просто выполняете «svn-переключение» на сервере на новый тег.Не сработало, несмотря на проверку?Переключитесь обратно и выясните, в чем дело.

Но будьте осторожны: ветвление в Subversion может быть болезненным, по крайней мере, до версии 1.5.Если вы или ваши разработчики не имеете опыта работы с ветками, вначале ожидайте некоторых хлопот и/или ошибок.Но пока вы сделали коммит, код не должен быть потерян (в худшем случае его просто будет сложно объединить).

Вашим разработчикам действительно следует научиться использовать ветвление;он может быть очень полезен для различных целей (не только для разработки релизов).

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

И последнее: никому не позволяйте вносить изменения на ваш рабочий сервер.Это может вызвать конфликты, и для их разрешения обычно требуется время.Не говоря уже о том, что это лишает вас возможности воспроизводить один и тот же выпуск на разных рабочих станциях (здесь все работает отлично!почему не на сервере?хм).

Answer 3

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

Answer 4

я бы использовал Хадсон.Помимо извлечения из svn и тегирования в нем (ссылка sblundy), он может быть полезен при управлении выпусками при правильном использовании. плагины.например, ты мог бы попробовать плагин для "продвижения" сборки, которые вы развертываете в рабочей среде, и храните список как самих продвигаемых сборок, так и журнал изменений/фиксаций для различных версий.