I have a PHP application that is written with Zend Framework. It uses Phing for a build system and PHPUnit for unit testing. All these parts have configuration settings. Zend uses
application.xml, Phing uses
build.xml and optionally some
build.properties, and PHPUnit uses
But where do I store information that is required by all three components? Think of database configuration (passwords for example).
In my case, the
application.xml has various sections (dev, staging, production) all with a different database configurations. I have recently integrated an ORM in my application and now I want to unittest my models. So I have a fourth database (unittesting) which is used by PHPUnit.
PHPUnit can handle fixture data but not database schemas. So, I was thinking I’d write a Phing build target that copies the database schema from production or staging to the unittest database. This way I have the added benefit that I can even unittest my database migration scripts. But in order to do that, Phing needs access to several databases at the same time.
My first gut instinct was to put all the configuration for all four databases in
build.properties and have Phing simply generate
phpunit.xml. But, it feels eh, dirty to have a build system generate configuration files.
What’s the best solution here? Or should I simply duplicatie the configuration details and not worry too much?
I could simply duplicate them. It’s only a few settings and they shouldn’t change often. But I bet that when they do change, I will have forgotten about the duplication (because it happens infrequently). Shared parameters include:
- Database configuration (dev, staging, production and unittests)
- Include paths. We use some older libraries that don’t work with autoloaders. So far we have partially solved this with an intelligent auto-prepend file.
- A few webservice API credentials
My first gut instinct was to put all the configuration for all four databases in build.properties and have Phing simply generate application.xml and phpunit.xml. But, it feels eh, dirty to have a build system generate configuration files.
Well, to fully generate them seems a bit dirty. But if the build system simply does token replacement from Phing’s build.properties file on .dist versions of your various config files, that seems ok to me.
For an example, see the source code of Dasprids blog.