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

Я начинаю новый проект в PHP, и мне бы хотелось получить некоторые отзывы от других разработчиков по их предпочтительной стратегии для развертывания PHP. Мне бы очень хотелось немного автоматизировать работу, чтобы после того, как изменения были зафиксированы, их можно быстро перенести на сервер разработки или производства.

У меня есть опыт развертывания с использованием Capistrano с Ruby, а также некоторые основные сценарии оболочки.

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

Дополнительная информация

В настоящее время разработчики работают над локальными установками сайта и фиксируют изменения в репозитории subversion. Первоначальные развертывания выполняются путем экспорта помеченного релиза из svn и загрузки его на сервер.

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

ОТВЕТЫ

Ответ 1

Для PHP SVN с Phing скрипты сборки - это путь. Phing похож на ANT, но написан на PHP, что делает его намного проще для разработчиков PHP для их нужд.

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

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

  • Проверьте отдельные копии веток на локальные машины.
  • Филиалы тестируются, а затем объединены в Trunk
  • Commits to Trunk автоматически создается phpUnderControl, запускает тесты и строит всю документацию, применяет дельта базы данных
  • Trunk запускается через тестирование качества и затем объединяется в нашу ветку "Стабильный"
  • Опять же, phpUnderControl автоматически создает Stable, запускает тесты и создает базу данных dokumenation и updates.
  • Когда мы будем готовы к производству, мы запускаем rsync script, который создает резервную копию Production, обновляет базу данных и затем подталкивает файлы. Команда rsync вызывается вручную, чтобы мы убедились, что кто-то наблюдает за продвижением.

Ответ 7

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

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

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

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

Соломон

Ответ 8

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

Но, если вам нужна система непрерывной интеграции для PHP, я думаю, Phing - лучший выбор для PHP. Тем не менее, я не тестировал его сам, так как я делаю ручной способ, например. УПП.

Ответ 9

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

Ответ 10

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

Ответ 11

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

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

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

Ответ 12

http://controltier.org/wiki/Main_Page

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

Ответ 13

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

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

Ответ 14

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

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

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

Ответ 15

Я предполагаю, что способ развертывания SVN не очень хорош. Потому что:

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

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

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

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