2 облачных сервера, один разработчик, один продукт; Каков хороший процесс развертывания?

Question

В настоящее время использую стек LAMP для моего веб-приложения.Мои dev и prod находятся в одном облачном экземпляре.Теперь я получаю новый экземпляр и хотел бы перенести среду разработки / тестирования на новый экземпляр, отделив его от среды prod.

Раньше это был простой скрипт Phing, который выполнял экспорт SVN в каталог prod (на который указывает мой vhost.conf).Как мне теперь сделать хороший процесс сборки с разделенными средами?

Подумав о переносе SVN-репозитория на сервер dev, а затем выполните ssh + svn push (возможно ли это с Phing?)

Какова наилучшая / распространенная практика для этого типа установки?

Подробнее:

В настоящее время я использую CodeIgniter для инфраструктуры MVC Phing для автоматизированных сборок для развертывания на локальном хосте.Веб-приложение также поддерживается несколькими скриптами CRON, написанными на Java .

Обновление:

Завершено с помощью Phing + Jenkins.Пока работает хорошо!

Answer 1

Мы используем Phing для развертывания, аналогичного тому, что вы описали. Мы также используем инфраструктуру Symfony для наших проектов (что не так важно для этого, но Symfony поддерживает концепцию различных сред, поэтому это плюс).

Однако нам все еще нужно создать различные файлы конфигурации для базы данных, фронт-контроллеров и т. Д.

Таким образом, мы получили папку с build.properties, которая определяет конфигурацию для разных сред (и в нашем случае также для разных клиентов, которым мы отправляем наш продукт). Эта папка связана с файловой структурой с помощью svn externals (опять же не обязательно).

Затем файл Phing build.xml принимает файл свойств в качестве параметра в командной строке, получает из него значения и создает все необходимые файлы конфигурации, контроллеры и другие файлы, специфичные для среды. Мы сохраняем конфигурацию в файлах шаблонов, а затем используем функцию копирования / фильтрации в Phing, чтобы заменить заполнители в шаблонах конкретными значениями.

Тогда вся задача настройки данной среды может быть такой простой:

phing configure-environment -DpropertyFile=./build_properties/build.properties.prod

В вашем файле сборки вы проверяете, определено ли свойство propertyFile, которое определяет файл свойств, и загружаете файл, используя <property file="./build_properties/build.properties.prod" override="true" />. Тогда вы просто делаете любую магию со значениями, которые вам нужны.

Вы по-прежнему можете использовать svn checkout / update и поместить все полученные файлы конфигурации в svn ignore (они будут сгенерированы с помощью phing). Мы фактически используем дополнительные шаги в Phing. Эти шаги в конце приводят к самораспаковывающемуся пакету установки оболочки Linux. Это производится автоматически в Дженкинс. Затем мы отправляем пакет нашим клиентам, или группа поддержки может получить пакет от Jenkins, и они могут выполнить все развертывание, просто выполнив его (мы по-прежнему предпочитаем развертывание вручную на производственных серверах), или Jenkins может развернуть его автоматически (например, для тестирования серверы).

Я буду рад написать больше информации, если это необходимо.

Answer 2

Я рекомендую использовать Capistrano (похоже, они не обновляли документы с момента перемещения сайта) и railsless-deploy для развертывания.В конечном итоге вам, вероятно, потребуется добавить дополнительные блоки приложений и выполнить другие задачи в рамках развертывания, поэтому выбор платформы, которая будет поддерживать это, может сэкономить вам много времени в будущем.Я использовал capistrano для двух развертываний PHP (один маленький и один большой), и хотя он не идеален, он работает хорошо.Он также обрабатывает весь код извлечения / обновления, перемещая символические ссылки и откатывая их, если что-то пойдет не так.*

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

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

Answer 3

Я сейчас использую аналогичный конфиг.Lamp + SVN + codeigniter + prd и dev серверы.

Я запускаю репозитории svn на dev.Я оформляю репозитории в корневой папке домена dev.Затем с помощью перехвата post-commit обновляйте корневую папку каждый раз, когда коммитит любой разработчик.

Когда мы довольны и полностью проверили код, который я ssh отправил на сервер prd, и rsync корня dev в корень prd.

Вот мое решение для разных конфигов.За пределами корневой папки у меня есть файл config.ini.Я анализирую файл в моем сценарии codeigniter constants.php.Это означает, что серверы prd и dev могут иметь отдельные настройки, и они никогда не будут находиться в репозиториях.

Если вам нужна помощь с пост-фиксацией, rsync и ini-код дайте мне знать.