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

161

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

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

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

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

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

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

GloryFish
источник
Милый :) Спасибо за редактирование.
GloryFish
1
@ Пол Томблин: О боже, я не могу перестать смеяться !!!!! Нет лучшего пути :)
Андрей Ринея
Может кто-нибудь ответить на это, пожалуйста - stackoverflow.com/questions/36034277/…
Sandeepan Nath

Ответы:

109

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

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

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

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

Эран Гальперин
источник
Я собирался опубликовать список того, что я делаю в моем магазине Windows / .NET, но это более или менее то, что вы получили здесь. +1
Даниэль Шаффер
Вы сталкивались с какими-либо недостатками использования svn co в качестве производственной среды? Я действительно не могу думать ни о каких недостатках, но не кажется "чистым" иметь svn co в качестве продукции? Почему не экспорт SVN или Rsync?
ChrisR
Из-за принципиальной разницы между co и экспортом - вы не можете вносить конкретные изменения, вам придется снова экспортировать все приложение. Это очень важное различие, которое делает жизнь намного проще
Эран Гальперин
36
Зачем ставить сайт внизу экрана? Если вы запустите каталог с выпусками / и укажете liveSite / через символьную ссылку на вашу папку в Releases /, то вы можете полностью извлечь сайт в новую папку / выпуски и мгновенно перевернуть символическую ссылку после завершения совместной работы? Нет необходимости в простоях (если вы не плохой рыдатель, который делает запрос во время этого переключения символической ссылки).
Джозеф Ласт
2
Кто отвечает за выполнение всех этих задач, таких как обновление SVN на рабочем месте и символическая ссылка в новом выпуске? Это финг? Это Дженкинс?
Даниэль Рибейро
24

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

Кайл Кронин
источник
Я годами делал то же самое на малых и средних проектах. Я должен сказать, что это прекрасно работает для меня. Вы должны любить простоту этого подхода.
Крис Аллен Лейн
3
Как вы справляетесь с базой данных при таком подходе?
32423hjh32423
1
@neilc К сожалению, от руки. Любые изменения в БД необходимо выполнить вручную перед отправкой.
Кайл Кронин
Я обычно включаю () файл PHP, который содержит конфигурацию БД, и вручную помещаю файл на сервер или тестовую машину. Таким образом, вы не сохраняете пароли в git и не случайно работаете с производственной базой данных.
Мэтт
Как вы настраиваете git, чтобы сделать это для вас? Есть ли руководство / учебник? Заранее спасибо.
Мигель Стивенс
14

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

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

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

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

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

Мартейн Хеемельс
источник
7

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

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

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

notneilcasey
источник
6

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

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

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


источник
3

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

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

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

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

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

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

Соломон

Соломон Хайкс
источник
2

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

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

Хенрик Пол
источник
2

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

Clint
источник
1

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


источник
1
так у вас есть каталоги .svn разбросанные по всему сайту? мой пуристический мозг идет против этого :)
Stann
Это только заботится об исходном коде. Для развертываний часто требуются другие действия - внесены изменения в базу данных, очищены кэши и т. Д.
Леонид Мамченков
1

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

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

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

troelskn
источник
1

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

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

Rafa
источник
1

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

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

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

Джесси Грейтхаус
источник
0

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

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

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

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

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

Эрик Фонг
источник
Открытие моего сервера SVN на весь мир, ни за что! Просто используйте ваш брандмауэр и аутентификацию через ssl, чтобы ограничить число тех, кто может видеть ваш код.
Шадок