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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

надеюсь, что это помогает!

Соломон

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

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

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

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

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

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

наконец, вы всегда можете написать Шелл файлы сценариев. До сих пор, это то, что я сделал.

http://controltier.org/wiki/Main_Page

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

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

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

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

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

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

Я думаю, что SVN развернуть путь не очень хорошо. Потому что:

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

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

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

ssh до 10 www server и svn up - это тоже проблема.