Как правильно использовать ваши 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 обычно хорошо подходит для работы, попробуйте:)