Какова ваша предпочтительная стратегия развертывания php?

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

Но если вам нужна система непрерывной интеграции для PHP, я думаю, Phing - лучший выбор для PHP. Я не тестировал это сам, так как я использую ручной способ, например. scp.

Для PHP подходит SVN со сценариями сборки Phing. Phing похож на МУРАВЕЙ, но написан на PHP, что значительно упрощает разработчикам PHP изменение для своих нужд.

Наша процедура развертывания выглядит следующим образом:

• Все разрабатывают на одном и том же локальном сервере на работе, у каждого разработчика есть касса на своей машине дома.
• Коммиты запускают обработчик после фиксации, который обновляет промежуточный сервер.
• Тесты запускаются на промежуточном сервере, если пройдут - продолжаем.
• Скрипт сборки Phing запускается:
• Останавливает рабочий сервер, переключая домен на страницу «В разработке».
• Запускает обновление SVN при проверке производства
• Запускает скрипт дельт схемы
• Запускает тесты
• Если тесты не пройдены - запускаем скрипт отката
• Если тесты пройдены, сервер возвращается к производственной проверке.

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

Я использую Apache Ant для развертывания на разные цели (dev, QA и live). Ant предназначен для работы с развертыванием Java, но предоставляет довольно полезное решение общего случая для развертывания произвольных файлов.

Синтаксис файла build.xml довольно легко изучить - вы определяете различные цели и их зависимости, которые запускаются, когда вы вызываете программу ant из командной строки.

Например, у меня есть цели для dev, QA и live, каждая из которых зависит от цели cvsbuild, которая проверяет последнюю версию head с нашего сервера CVS, копирует соответствующие файлы в каталог сборки (используя тег набора файлов), а затем rsync каталог сборки на соответствующий сервер. Есть несколько причуд, которые нужно изучить, и кривая обучения не совсем плоская, но я делал это годами без проблем, поэтому я бы порекомендовал его для вашей ситуации, хотя мне любопытно, какие еще ответы я Посмотрим в этой ветке.

У меня есть рабочая копия ветки выпуска SVN на сервере. Обновить сайт (когда нет изменений схемы) так же просто, как ввести команду обновления SVN. Мне даже не нужно переводить сайт в офлайн.

Я делаю вещи вручную, используя Git. Один репозиторий для разработки, который помещает git push --mirror в публичное репо, и живой сервер - это третье репо, извлеченное из него. Я полагаю, что эта часть такая же, как и ваша собственная установка.

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

Я запускаю живой сервер прямо из главной ветки, и когда я закончу с другой веткой и буду готов ее объединить, на какое-то время переключу сервер в эту ветку. Если он сломается, его возврат к мастеру займет секунды. Если он работает, он объединяется с мастером и обновляется живой код. Я предполагаю, что аналог этого в SVN будет иметь две рабочие копии и указывать на живую через символическую ссылку.

Я знаю, что Phing упоминался несколько раз, но мне очень повезло с phpUnderControl. Для нас мы

1. Получение отдельных копий веток на локальные машины
2. Ветви тестируются, а затем объединяются в магистраль.
3. Коммиты в Trunk автоматически создаются phpUnderControl, запускают тесты и собирают всю документацию, применяет дельты базы данных
4. Транк проходит тестирование качества, а затем объединяется с нашей стабильной веткой.
5. Опять же, phpUnderControl автоматически создает Stable, запускает тесты, создает документацию и обновляет базу данных.
6. Когда мы готовы приступить к производству, мы запускаем сценарий rsync, который выполняет резервное копирование в производственной среде, обновляет базу данных, а затем подталкивает файлы вверх. Команда rsync вызывается вручную, чтобы мы были уверены, что кто-то наблюдает за продвижением.

В настоящее время я развертываю PHP используя Git. Простое производство с помощью git push - это все, что нужно для обновления моего рабочего сервера последней копией из Git. Это легко и быстро, потому что Git достаточно умен, чтобы пересылать только изменения, а не весь проект заново. Это также помогает сохранить резервную копию репозитория на веб-сервере в случае отказа оборудования на моем конце (хотя я также нажимаю на GitHub, чтобы быть в безопасности).

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

Другой вариант - использовать Capistrano. Очевидно, что он не так хорошо интегрируется с PHP, как с Ruby, но вы все равно можете использовать его для многих вещей.

Наконец, вы всегда можете писать сценарии оболочки. Пока это то, что я сделал.

Мы используем Webistrano, веб-интерфейс для Capistrano, и очень им довольны.

Webistrano позволяет выполнять многоэтапное развертывание в нескольких средах из SVN, GIT и других. Он имеет встроенную поддержку отката, поддержку отдельных ролей сервера, таких как web, db, app и т. д., И развертывается параллельно. Он позволяет вам переопределять параметры конфигурации на нескольких уровнях, например на каждом этапе, и регистрирует результаты каждого развертывания, при необходимости отправляя их по почте.

Несмотря на то, что Capistrano и Webistrano являются приложениями Ruby, синтаксис «рецептов» развертывания достаточно прост и понятен любому программисту PHP. Первоначально Capistrano создавался для проектов Ruby on Rails, но легко поддерживает проекты PHP.

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

Чтобы обеспечить максимально быстрое развертывание, мы установили метод fast_remote_cache, который обновляет кеш рабочей копии svn на удаленном сервере, а затем жестко связывает результат.

Думаю, способ развертывания SVN не очень хороший. Так как:

Вам нужно открыть доступ к SVN для всего мира

иметь много .svn на производственных веб-серверах

Я думаю, что Phing для создания ветки + объединение всех js / css + замена стадии config + загрузка ssh на все серверы www - лучший способ.

ssh к серверу 10 www и svn up тоже проблема.

http://controltier.org/wiki/Main_Page

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

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

Вместо этого перехватчики Subversion используются только для развертывания на тестовом / промежуточном сервере. Код развертывается в производственной среде в конце итерации, после выполнения тестов и проверки работоспособности. Для самого развертывания я использую специально созданный Makefile, который использует rsync для передачи файлов. Makefile также может запускать сценарии миграции на удаленном сервере, приостанавливать / возобновлять работу веб-серверов и серверов баз данных.

В ходе моей работы я и моя команда разработали Phing-ориентированную замену деплоя capistrano, а также добавили некоторые полезности, доступные в phing, такие как тестирование PHPUnit, phpcs и PHPDocumentor. Мы сделали его репозиторием git, который можно добавить в проект в качестве подмодуля в git, и он работает очень хорошо. Я прикрепил его к нескольким проектам, и он достаточно модульный, чтобы его можно было легко заставить работать с любым проектом в любой из наших сред (стадия, тестирование, производство и т. д.).

С помощью скриптов сборки phing вы можете запускать их из командной строки вручную, и мне также удалось автоматизировать процедуры сборки / развертывания с помощью Hudson, а теперь и Jenkins ci.

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

Я опаздываю на вечеринку, но думал, что поделюсь нашими методами. Мы используем Phing с Phingistrano, который обеспечивает Phing-подобную функциональность с помощью предварительно созданных файлов сборки. Это очень круто, но работает, только если вы сейчас используете Git.

Альтернативой самодельным сценариям развертывания является развертывание на платформе как услуге, которая абстрагирует за вас большую часть этой работы. PaaS, как правило, предлагает собственный инструмент развертывания кода, а также масштабирование, отказоустойчивость (например, отсутствие отказа при отказе оборудования) и, как правило, отличный инструментарий для мониторинга, проверки журналов и т. д. заведомо исправная конфигурация, которая будет постоянно обновляться (для вас одной головной болью меньше).

PaaS, который я бы порекомендовал, - это dotCloud, помимо PHP (см. их краткое руководство по PHP), он также может развертывать MySQL, MongoDB и целый ряд дополнительных сервисов. У него также есть приятные плюсы, такие как развертывание с нулевым временем простоя, мгновенный откат, полная поддержка SSL и веб-сокетов и т. д. И есть бесплатный уровень, который всегда хорош :)

Конечно, я немного предвзят, так как работаю там! Другие варианты, которые стоит проверить в дополнение к dotCloud, - это Pagodabox и Orchestra (теперь часть Engine Yard).

Надеюсь это поможет!

Соломон