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

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

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

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

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

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

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

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

Также, создавая несколько копий settings.php(один для localhost, beta и prod). Затем, используя оболочку script который экспортирует из 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. Но то, что abt.htaccess, вы не можете проверить, как выше в .htaccess.

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

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

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

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

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

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

Спасибо заранее,

ocptime

Ответ 1

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

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

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

Ответ 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, поэтому он отлично работает в командной строке.

Ответ 3

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

Ответ 4

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

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

он зависит от групп инструментов bash, rsync, git, link, но web ui обычно хорошо подходит для работы, попробуйте:)