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

Question

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

Я проверяю последний код на свой локальный компьютер в каталог под названием «myapp_latest_svn». У меня есть сайт и местоположение конкретного код в моей основной settings.php, который имеет H_PATH = «http://myapp.com» настройки конфигурации & дБ для DB_HOST, db_user_name и пароль_базы_данного, который, как вы знаете, в разных локальных настройках машины (где LOCALHOST/MyApp. com - это просто псевдоним Apache) & на сервере (на сайте myapp.com).

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

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

Тогда в выпуске я должен помнить, что все соответствующие файлы-разработчики должны быть заменены на их производственную копию. Теперь мне пришлось вручную отредактировать настройки production.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 не находится в управлении версиями, поэтому db не является проблемой для меня, только settings.php и .htaccess.

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

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

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

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

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

ocptime

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Следующим шагом будет ключ для вас: магазин TEMPLATES ваших конфигурационных файлов и 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 

build/properties/production.properties

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

общий/сборка/сборка.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 4

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

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

это зависит от групп Баша инструментов, Rsync, мерзавец, ссылка, но веб-интерфейс в целом хорошо для работы, попробовать :)