Я начинаю новый проект на PHP, и мне бы хотелось получить обратную связь от других разработчиков по их предпочтительной стратегии для развертывания PHP. Я хотел бы немного автоматизировать работу, чтобы после того, как изменения были зафиксированы, их можно быстро перенести на сервер разработки или производства.
У меня есть опыт развертывания с использованием Capistrano с Ruby, а также некоторые основные сценарии оболочки.
Перед тем, как я сначала погрузиться в голову, было бы здорово услышать, как другие подошли к этому в своих проектах.
В настоящее время разработчики работают над локальными установками сайта и фиксируют изменения в репозитории subversion. Первоначальные развертывания производятся путем экспорта помеченного релиза из svn и загрузки его на сервер.
Дополнительные изменения обычно производятся по частям, вручную загружая измененные файлы.
Для PHP SVN с скриптами построения Phing – это путь. Phing похож на ANT, но написан на PHP, что делает его намного проще для разработчиков PHP для их нужд.
Наша процедура развертывания следующая:
Существует также phpUnderControl , который является сервером непрерывной интеграции. Я не считаю это очень полезным для веб-проектов, если честно.
В настоящее время я использую 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-развертыванием, но он предоставляет довольно полезное решение для развертывания произвольных файлов.
Синтаксис файла build.xml довольно прост в освоении – вы определяете разные цели и их зависимости, которые запускаются при вызове программы ant в командной строке.
Например, у меня есть цели для dev, QA и live, каждый из которых зависит от цели cvsbuild, которая проверяет последнюю ревизию главы с нашего сервера CVS, копирует соответствующие файлы в каталог сборки (используя тег набора файлов), а затем rsyncs создает каталог сборки на соответствующий сервер. Есть несколько причуд, чтобы учиться, и кривая обучения не совсем плоская, но я делаю это так много лет без проблем, поэтому я бы рекомендовал ее для вашей ситуации, хотя мне любопытно, какие другие ответы я Посмотрим на эту тему.
Я делаю вещи вручную с помощью Git. Один репозиторий для разработки, который получает git push --mirror для публичного репо, а живой сервер – это третье репо. Эта часть, я полагаю, такая же, как и ваша собственная настройка.
Большая разница в том, что я использую ветви почти для каждого изменения, над которым я работаю (у меня сейчас около 5), и они имеют тенденцию перебрасываться между ними. Мастер-ветвь не изменяется напрямую, за исключением объединения других ветвей.
Я запускаю прямой сервер непосредственно из ведущей ветки, и когда я закончил с другой ветвью и готов к ее объединению, некоторое время переверните сервер на эту ветку. Если он сломается, вернуть его хозяину займет секунды. Если он работает, он объединяется в мастер и обновляется живой код. Я предполагаю, что аналогия этого в SVN будет иметь две рабочие копии и указывать на живую через символическую ссылку.
Я знаю, что Phing упоминается несколько раз, но мне очень повезло с phpUnderControl . Для нас мы
альтернативой самодельным сценариям развертывания является развертывание на платформе как услуга, которая абстрактно отнимает много этой работы для вас. PaaS, как правило, предлагает свой собственный инструмент для развертывания кода, а также масштабирование, отказоустойчивость (например, не сбой при сбое оборудования) и, как правило, отличный инструментарий для мониторинга, проверки журналов и т. Д. Также существует преимущество развертывания хорошо известная хорошая конфигурация, которая будет поддерживаться в актуальном состоянии с течением времени (одна головная боль для вас).
PaaS, который я бы рекомендовал, – dotCloud , в дополнение к PHP ( см. Их быстрый запуск PHP ), он также может использовать MySQL, MongoDB и целую кучу дополнительных сервисов. Он также имеет приятные лакомства, такие как развертывание с нулевым временем простоя, мгновенный откат, полная поддержка SSL и websocket и т. Д. И есть свободный уровень, который всегда хорош 🙂
Конечно, я немного предвзятый, так как я там работаю! Другие варианты, которые стоит проверить в дополнение к dotCloud, – Pagodabox and Orchestra (теперь часть Engine Yard).
Надеюсь это поможет!
Соломон
То, что вы автоматически и слепо принимаете изменения с репозитория на производственные серверы, звучит опасно. Что делать, если ваш совершенный код содержит ошибку регрессии, поэтому ваше производственное приложение становится глючным?
Но если вам нужна система непрерывной интеграции для PHP, я думаю, что Phing – лучший выбор для PHP. Я не тестировал его сам, хотя, как я делаю ручной способ, например, scp.
Я опаздываю на вечеринку, но я думал, что поделился бы нашими методами. Мы используем Phing с Phingistrano , который предоставляет функции, подобные Capistrano, для Phing через предварительно построенные файлы сборки. Это очень здорово, но работает, только если вы используете Git на данный момент.
У меня есть рабочая копия ветви релиза SVN на сервере. Обновление сайта (при отсутствии изменений схемы) так же просто, как выдача команды обновления SVN. Мне даже не нужно снимать сайт в автономном режиме.
Phing, вероятно, лучше всего, если вы можете выдержать боль от файлов конфигурации xml. У системы Symfony есть собственный порт грабли (pake), который работает достаточно хорошо, но довольно тесно связан с остальной частью Symfony (хотя вы, вероятно, могли бы их разделить).
Другой вариант – использовать Capistrano. Очевидно, он не интегрируется также с PHP, как и с Ruby, но вы все равно можете использовать его для многих вещей.
Наконец, вы всегда можете писать сценарии оболочки. Пока это то, что я сделал.
http://controltier.org/wiki/Main_Page
мы будем использовать его для развертывания и обслуживания на нескольких серверах.
Один год поздно, но … В моем случае развертывание не автоматическое. Я нахожу опасным развертывание кода и запуск сценариев миграции базы данных автоматически.
Вместо этого перехватчики перехвата используются для развертывания только для тестирования / промежуточного сервера. Код развертывается для производства в конце итерации после выполнения тестов и гарантирует, что все будет работать. Для самого развертывания я использую специально созданный Makefile, который использует rsync для передачи файлов. Файл Makefile также может запускать сценарии миграции на удаленном сервере, приостанавливать / возобновлять веб-серверы и базы данных.
В моей работе я и моя команда разработали замену Phing для развертывания capistrano, и мы также включили некоторые полезные свойства, доступные в phing, например, тестирование PHPUnit, phpcs и PHPDocumentor. Мы сделали это git-репо, которое можно добавить в проект как подмодуль в git, и он работает очень хорошо. Я приложил его к нескольким проектам, и он достаточно модульный, что легко заставить его работать с любым проектом в любой из наших нескольких сред (постановка, тестирование, производство и т. Д.).
С помощью скриптов phing build вы можете запускать их из командной строки вручную, и мне также удалось автоматизировать процедуры сборки / развертывания с помощью Hudson и теперь Jenkins ci.
Я не могу опубликовать какие-либо ссылки сейчас, потому что репо еще не открыто, но мне сказали, что мы скоро откроем источник, поэтому, пожалуйста, не стесняйтесь обращаться ко мне, если вы заинтересованы, или если у вас есть любые вопросы по автоматизации развертывания с помощью phing и git.
Я предполагаю, что развертывание SVN не очень хорошо. Потому как:
Вам нужно открыть доступ SVN для всего мира
имеют много .svn на рабочих веб-серверах
Я думаю, что Phing для создания ветки + объединяет все js / css + замену stage config + ssh upload на все www-серверы лучшим способом.
ssh to 10 www server и svn up тоже проблема.