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

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

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

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

Дальнейшая информация

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

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

Для PHP лучше всего использовать SVN со скриптами сборки Phing . Phing похож на ANT, но написан на PHP, что облегчает разработчикам PHP модификацию для своих нужд.

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

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

Также есть 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, копирует соответствующие файлы в каталог сборки (используя тег fileset), а затем rsyncs каталог сборки на соответствующий сервер. Есть несколько причуд, чтобы учиться, и кривая обучения не совсем плоская, но я делал это годами без проблем, поэтому я рекомендую это для вашей ситуации, хотя мне любопытно, какие другие ответы я посмотрю в этой теме.

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

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

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

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

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

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

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

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

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

Соломон

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

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

Я опаздываю на вечеринку, но думал, что поделюсь нашими методами. Мы используем Phing с Phingistrano , который предоставляет Capistrano-подобную функциональность Phing через предварительно собранные файлы сборки. Это очень круто, но работает, только если вы используете 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, phpcs и PHPDocumentor. Мы сделали это git-репо, которое можно добавить в проект как подмодуль в git, и оно работает очень хорошо. Я прикрепил его к нескольким проектам, и он достаточно модульный, чтобы его можно было легко использовать с любым проектом в любой из наших нескольких сред (подготовка, тестирование, производство и т. Д.).

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

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

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

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

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

Я думаю, что Phing для создания ветки + объединить все JS / CSS + заменить этап конфигурации + SSH загрузки на все серверы WWW лучше.

SSH на 10 WWW сервера и SVN Up также проблема.