Как да управлявате различни настройки на php.ini при производство и разработка?

Има ли най-добра практика за управление на конфигурациите на php.ini от разработката до производството? Очевидно може да се направи ръчно, но това е предразположено към човешка грешка. Бих искал да опитам да държа производствения файл в контрола на версиите и след това евентуално да променя автоматично версията за разработка. Имах мисли или идеи, които не знам дали са осъществими:

  1. php.ini включва - просто включете настройките за разработка в края на файла?
  2. условни зареждания от apache conf?
  3. напишете скрипт, който когато php.ini се промени, се генерира динамична версия на phpdev.ini - (знам, че това може да се направи)
  4. използвайте настройките на php по време на изпълнение за грешки на дисплея - мисля, че това има ограничения, защото ако скриптът има фатални грешки, тогава няма да изпълни настройката по време на изпълнение.
  5. резервен план - запазете производствената версия в SC и променете ръчно phpdev.ini според нуждите. След това, ако се направят ръчни грешки, те се правят на ниво разработка.

php configuration apache .htaccess
person Nick    schedule 22.01.2012    source източник
comment
Какъв е процесът на внедряване на вашето приложение? По-конкретно, когато внедрявате приложението си, внедрявате ли код или целия стек от технологии?   -  person jcmeloni    schedule 22.01.2012
comment
Мисля, че може да се нуждая и от някои най-добри практики за това. В идеалния случай искам да го направя автоматизиран/доказателство за глупаци (ако има такова нещо). Понастоящем внедряването е хакване/персонализиран скрипт за надстройка на db и svn актуализация   -  person Nick    schedule 24.01.2012

Отговори (2)


arrow_upward
2
arrow_downward

  1. Съхранявайте вашия ini във вашето хранилище за изходен код в различни директории, наречени според техните среди: environments/{dev,qa,staging,prod}/php.ini
  2. Във всяка среда направете следното: rm /etc/php.ini; ln -s /var/www/site/environments/prod/php.ini /etc/php.ini

По този начин получавате предимствата на контрола на ревизиите и не е необходимо да редактирате всяка ръчно.

person Theodore R. Smith    schedule 22.01.2012
comment
Това изглежда като най-бързия начин да постигна това, което искам. Благодаря ви за предложението. - person Nick; 30.01.2012
comment
Радвам се, че помага. Не забравяйте да гласувате за отговорите, които приемате. - person Theodore R. Smith; 30.01.2012
comment
Мислех малко повече за това и все още се чудя какво пречи да се направи промяна във версията за разработка, която се тества, но след това производствената версия не се актуализира със съответната промяна? Това може да причини проблеми в приложението, когато се премести в производствена среда. - person Nick; 02.02.2012
comment
ако наистина си анален, направи го така, че файлът PHP.ini да не може да се променя от никой друг освен от root. Вашият хипотетичен проблем е свързан с управлението на промените; нищо не може наистина да предпази една организация от липсата му или потребителите да се каубойстват на кода. - person Theodore R. Smith; 04.02.2012

arrow_upward
0
arrow_downward

Не знам точно дали това е, което търсите, но лично аз обичам да извършвам всички модификации на php.ini, които не са необходими за сигурността, чрез настройките на apache virtualhost, напр. виртуален хост за разработка:

    ServerName sb.local
    ServerAlias sb.local
    DocumentRoot /srv/some-site

    php_value session.cookie_domain "sb.local"
php_value date.timezone "America/New_York"
php_value mbstring.func_overload 7
php_value default_charset "utf-8"
AddDefaultCharset utf-8 

php_value session.gc_maxlifetime "990000"
php_value error_reporting 30711
# 30711 = E_ALL ^ E_NOTICE
php_value display_errors "On"
php_value display_startup_errors "On"
php_value log_errors "On"
php_value html_errors "On"

и т.н

person Kzqai    schedule 14.06.2013