Мы создаем веб-приложение и почти готовы к развертыванию на рабочем сервере. Мы используем Subversion для управления версиями, и теперь мне интересно, какой способ лучше всего было бы развернуть на стадии подготовки, а затем в производство.
Прямо сейчас мы разрабатываем и тестируем с двумя людьми локально на наших собственных машинах и фиксируемся на нашем промежуточном сервере, который является нашим сервером SVN.
Я знаю, что есть хук post-commit.tmpl, который может запускать скрипт? Кто-нибудь знает хороший ресурс для таких сценариев.
Любые подсказки приветствуются! Мы ищем простой способ развернуть и, возможно, вернуть наш код к предыдущей версии.
Subversion - это система контроля версий, а не система развертывания. Не используйте это. Поскольку вы сейчас делаете все вручную (сборка и тестирование), я бы также развернул вручную, это также может означать, что вы пишете несколько сценариев, которые проверяют правильную версию из подрывной деятельности и развертывают ее в любой среде, в которой вы хотите.
Если вы хотите автоматизировать больше, я бы порекомендовал CI-сервер или какое-либо решение для развертывания для этого. Мы начинаем использовать Hudson для тестирования и развертывания (по крайней мере, для среды песочницы). Мы не собираемся использовать его в производстве. Потому что мы еще не проверяли плагин продвижения. Изучая серверы CI, я заметил, что коммерческие системы обычно лучше поддерживают управление выпусками.
Этот вопрос на самом деле касается процедур выпуска (и инструментов), а не системного администрирования, но вот мой лучший ответ:
Любая последняя версия Subversion отлично справляется с вашими потребностями в управлении конфигурацией, но, как сказал Питер, это не инструмент развертывания. Один из вариантов - встроить развертывание в вашу обычную инфраструктуру сборки (например, make deploy) и управлять своими правилами развертывания вместе с кодом.
С точки зрения управления конфигурацией вам необходимо отслеживать все, что вашему приложению необходимо для работы, включая код, внешние библиотеки (в определенных версиях), веб-сервер, версии ОС и т. Д. 'Make deploy' должен попытаться обеспечить все эти вещи существует до того, как он попытается развернуть новую версию.
Такие инструменты, как Hudson, также могут выполнять развертывание за вас, но вам все равно нужно указать ему, что делать, и я просто предпочитаю, чтобы мои процедуры управления конфигурацией были как можно проще. Один из примеров - позволить Hudson вызывать make deploy, но не хранить в Hudson никакой другой информации, которую вам нужно было бы восстановить для воссоздания на дополнительных машинах.
Как часто вы собираетесь выпускать выпуски, которые необходимо развернуть? Я бы подумал о том, чтобы пометить ваше веб-приложение в теги / и иметь механизм после фиксации, который знает, что теги / webapp-1.0.4 необходимо экспортировать в ваш корневой веб-каталог. Если ваше веб-приложение велико, подумайте о том, чтобы перехватчик помещал в / tmp специальный файл, который cronjob проверяет каждую минуту и предпринимает соответствующие действия.
Если вы хотите получить более подробный ответ, просьба уточнить расписание выпуска, размер кодовой базы, выбор языка, среду ОС и зависимости.
Это можно сделать несколькими способами:
Используйте сервер сборки
Я слышал о командах, использующих для этого CCNET.net или FinalBuilder Server. По сути, в сценарии сборки есть код для отправки последней сборки каждый раз, когда кто-то проверяет ее. Я бы не рекомендовал это для производства. Однако это должно работать нормально для промежуточной среды.
Я не очень знаком с серверами сборки в Linux, но знаю, что их несколько. Также для этого можно использовать скрипты Ant и даже Make.
Поместите рабочую копию на промежуточный сервер
Просто выполните проверку и сопоставьте правильную папку с корнем веб-приложения. Кто-то из команды должен будет вручную обновить эту рабочую копию, но это дает вам возможность вернуться к предыдущей версии при необходимости.
Предостережения
Вам необходимо убедиться, что вы исключили папки .svn при указании веб-сайта на рабочую копию.
Я бы не рекомендовал использовать для этого сценарий ловушки Subversion. Вы можете использовать любой скриптовый движок, доступный в Linux, для выполнения скриптов после фиксации. Я набрал в Google "post-commit hook script linux" и получил несколько хороших результатов.
Мы также используем Subversion для управления нашим источником, но используем Webistrano для развертывания из Subversion на наши серверы.
Webistrano это веб-интерфейс для Capistrano, популярный инструмент развертывания и автоматизации в сообществе Ruby. Он позволяет описывать процесс развертывания в сценариях Ruby (большая часть функций встроена). Он довольно гибкий и понятный. Развертывание и откат развертываний просты, как и подключение других задач, которые необходимо выполнить, таких как очистка кешей или миграция баз данных.
Мне удалось это сделать, создав свежий после фиксации файл со следующими двумя строками:
#!/bin/bash
ssh -i /path/to/key-file -pSSH-PORT user@hostname svn update /path/to/project/folder/