Как правильно развернуть ваши PHP-приложения?

Question

Как правильно развертывать приложения от разработки до производства и как работать с несколькими конфигурациями сайта. Все мои разработки выполняются через SVN, расположенный в var / svn / myapp / trunk и фактический производственный код находится в /var/www/myapp.

Я проверяю последний код на моем локальном компьютере в каталоге с именем "myapp_latest_svn". В моем основном файле settings.php есть код, специфичный для сайта и местоположения, который имеет H_PATH = 'http://myapp.com' & db config настройки для db_host, db_user_name и db_password, которые, как вы знаете, отличаются в настройки локального компьютера (где localhost / myapp.com - это просто псевдоним Apache) и на рабочем сервере (работающий сайт работает на myapp.com).

Также файл .htaccess отличается от файла на рабочем сервере. Короче говоря, между разработкой и производством есть ряд отличий.

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

Тогда в выпуске я должен помнить, чтобы заменить все соответствующие файлы dev на их производственный аналог. Теперь мне пришлось вручную отредактировать производственные settings.php & .htaccess, чтобы отразить изменения, характерные для сайта.

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

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

Также, сделав несколько копий settings.php (по одной для localhost, beta и prod). Затем с помощью сценария оболочки который экспортирует из SVN, а затем, когда экспорт завершен, он заменяет файл settings.php на правильный файл settings.php, в зависимости от места, в котором мы развертываем. Таким образом, все автоматизировано. Но это также неудачный путь.

Последний путь -

if( eregi ("myapp.com$", $_SERVER['HTTP_HOST']) ){

    define('H_PATH', 'myapp.com');

} else {

    define('H_PATH', 'localmyapp.com');

}

Это нормально, что касается settings.php. Но что касается .htaccess, вы не можете проверить, как указано выше в .htaccess.

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

Моя схема БД не находится под контролем версий, поэтому db не проблема для меня, только settings.php и .htaccess.

Также, как я могу сказать svn не обновлять некоторые каталоги, так как это также зависит от сайта (/ log, / cache, / assets, / downloads). Также мне нужно сохранить доступ к записи apache (www_data) для указанных выше файлов.

Наконец, я не хочу копировать пустой каталог соединительных линий и файлы .svn на рабочий сервер при экспорте.

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

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

Заранее спасибо,

ocptime

Answer 1

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

Я не храню конфигурационные файлы в моем удаленном репо - когда я оформляю заказ в dev, я могу добавить их один раз, а затем игнорировать, чтобы я не проверил их случайно. Когда дело доходит до развертывания, мой рецепт cap deploy настроен так, чтобы он записывал файлы настроек в развернутую версию. Таким образом, мне никогда не придется беспокоиться о развертывании и пропуске чего-либо критического.

Cap также заботится о любых загруженных ресурсах (с помощью ссылок на каталоги, чтобы они оставались на своем месте при каждом развертывании), а также автоматически создает резервные копии всех файлов активов и базы данных при развертывании в Amazon S3. Довольно изящно, а?

Answer 2

У меня есть задача Phing под названием config, которая спрашивает меня, для какой среды я хотел бы настроить код. Задача принимает несколько возможных значений: локальная, разработка, постановка, производство и т. Д.

Как только я сообщаю об этом среде, он читает в соответствующем файле .properties (то есть local.properties, production.properties и т. Д.)

Следующий шаг будет для вас ключевым: сохраните ШАБЛОНЫ ваших файлов конфигурации и htaccess, затем запустите на них задачу filterChain replaceTokens, чтобы их токены были заменены значениями из файла свойств.

Создать эти файлы:

общее / строительство / шаблоны / settings.tpl

define('H_PATH','##H_PATH##');
define('ENVIRONMENT', '##ENVIRONMENT##');

сборка / шаблоны / htaccess.tpl

http://##H_PATH##

сборки / свойства / local.properties

site.H_PATH = localmyapp.com
site.ENVIRONMENT = local

сборки / свойства / production.properties

site.H_PATH = myapp.com
site.ENVIRONMENT = production

общее / строительство / build.xml

<target name="config">
   <input propertyname="env" validargs="local,production">Enter environment name:</input>
   <property file="build/properties/${environment}.properties" />
   <copy file="build/templates/settings.tpl" 
     tofile="config/settings.php" overwrite="true"> 
     <filterchain>
      <replacetokens begintoken="##" endtoken="##">       
          <token key="H_PATH" value="${site.H_PATH}" />
          <token key="ENVIRONMENT" value="${site.ENVIRONMENT}" />
      </replacetokens>          
     </filterchain>
   </copy>      
   <copy file="build/templates/htaccess.tpl" 
     tofile="public/.htaccess" overwrite="true">    
     <filterchain>
      <replacetokens begintoken="##" endtoken="##">       
          <token key="H_PATH" value="${site.H_PATH}" />                                                           
      </replacetokens>          
     </filterchain>
   </copy>              
   <echo msg="Configured settings.php and .htaccess for ${environment}" />              
</target>                               

Теперь, когда вы хотите настроить сайт для локального запуска, просто наберите:

phing config

затем введите:

local

и нажмите возврат. Это оно! Одним из огромных преимуществ этого является то, что вам больше не нужны ЛЮБЫЕ операторы if / else в вашем коде. Кроме того, он не зависит от переменных $ _SERVER, поэтому он будет отлично работать в командной строке.

Answer 3

Я храню свои файлы настроек и .haccess в SVN с переименованными именами файлов, например settings.php.example и .htaccess.example. Таким образом, когда я создаю новый релиз, мне не нужно беспокоиться о перезаписи.

Answer 4

вы можете думать о Capistrano, Magallanes, Deployer, но они также являются сценариями. Я могу порекомендовать вам попробовать walle-web , инструмент для развертывания, написанный на PHP с yii2 из коробки. Я провел его в нашей компании в течение нескольких месяцев, он работает без сбоев при развертывании тестов, симуляций, производственной среды.

Он поддерживает настройку задач перед развертыванием, после развертывания, после выпуска, затем вы можете изменить конфигурацию среды, например cp db_test.php db.php.

это зависит от групп инструментов bash, rsync, git, link, но веб-интерфейс, как правило, хорошо работает, попробуйте:)