2011-07-28 12 views
8

Tengo una aplicación PHP que está escrita con Zend Framework. Utiliza Phing para un sistema de compilación y PHPUnit para pruebas unitarias. Todas estas partes tienen configuraciones de configuración. Zend usa application.xml, Phing usa build.xml y opcionalmente build.properties, y PHPUnit usa phpunit.xml.¿Cómo almacenar la configuración compartida para zend, phing y phpunit?

¿Pero dónde almaceno la información requerida por los tres componentes? Piense en la configuración de la base de datos (contraseñas, por ejemplo).

En mi caso, el application.xml tiene varias secciones (desarrollo, montaje, producción) todas con configuraciones de bases de datos diferentes. Recientemente he integrado un ORM en mi aplicación y ahora quiero probar mis modelos. Así que tengo una cuarta base de datos (unittesting) que es utilizada por PHPUnit.

PHPUnit puede manejar datos de aparatos pero no esquemas de bases de datos. Por lo tanto, estaba pensando en escribir un objetivo de compilación Phing que copie el esquema de la base de datos desde la producción o la puesta en escena a la base de datos unittest. De esta forma, tengo el beneficio adicional de que incluso puedo probar mis scripts de migración de base de datos. Pero para hacer eso, Phing necesita acceder a varias bases de datos al mismo tiempo.

Mi primer instinto fue poner toda la configuración para las cuatro bases de datos en build.properties y hacer que Phing simplemente genere application.xml y phpunit.xml. Pero, se siente eh, sucio tener un sistema de compilación generar archivos de configuración.

¿Cuál es la mejor solución aquí? ¿O debería simplemente duplicar los detalles de configuración y no preocuparme demasiado?

Pensamientos

yo podría simplemente duplicarlas. Son solo unas pocas configuraciones y no deberían cambiar a menudo. Pero apuesto a que cuando cambien, me habré olvidado de la duplicación (porque ocurre con poca frecuencia). parámetros comunes incluyen:

  • configuración de base de datos (dev, puesta en escena, la producción y unittests)
  • incluyen rutas. Usamos algunas bibliotecas antiguas que no funcionan con cargadores automáticos. Hasta ahora, hemos resuelto parcialmente esto con un archivo inteligente de preajuste automático.
  • credenciales de API
  • Algunos de servicio web
+0

¿Cuánta duplicación estás enfrentando y con qué frecuencia cambia? – hakre

+0

Es un puñado de variables y no deberían cambiar con demasiada frecuencia. Actualizaré mi pregunta un poco. –

+1

Nota al margen: descubrí que la creación de un autocargador personalizado para bibliotecas antiguas y su inserción en la pila del autocargador Zend funciona como un milagro. De repente, todas mis ridículas llamadas en línea 'require' pueden eliminarse y el código de consumidor _feels_ queda más limpio. –

Respuesta

7

Mi primer instinto era poner toda la configuración de todas las bases de datos en cuatro build.properties y tienen Phing simplemente generar aplicacion.xml y phpunit.xml. Pero, se siente eh, sucio tener un sistema de compilación generar archivos de configuración.

Bueno, para generarlos completamente parece un poco sucio. Pero si el sistema de compilación simplemente reemplaza el token del archivo build.properties de Phing en las versiones .dist de sus diversos archivos de configuración, eso me parece bien.

Para ver un ejemplo, vea source code of Dasprids blog.

+0

+1 Esto sonaba como una gran idea cuando lo leí en la pregunta también. El sistema de compilación debe crear lo que necesite la aplicación a partir de elementos de origen, y un único archivo de propiedades unificado es un gran elemento de origen. :) –

+0

Esto es lo que hacemos también con un diseño similar (Symfony en lugar de Zend Framework). Es simple de implementar, bastante simple de mantener y bastante infalible. – poisson

+0

Gracias. Esto es lo que implementé ahora. Lo hice un elemento de construcción condicional. Una vez construido, no se reconstruirá (a menos que se proporcione '-Doverwrite') para que la gente no los sobrescriba accidentalmente. –

Cuestiones relacionadas