How to store shared configuration for zend, phing and phpunit?

Question

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 phpunit.xml.

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 application.xml and 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?

Thoughts

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

Thomasson

How much duplication are you facing and how often does it change? – Basically

It's a handful of variables and they shouldn't change too often. I'll update my question a bit. – Thomasson

Side note: I have found that creating a custom autoloader for old libraries and pushing it onto the Zend autoloader stack works like a miracle. Suddenly, all my goofy inline require calls can be removed and consumer code feels cleaner. – Waggoner

I believe you David. Problem is that it's hard to get working for e.g. PEAR libraries with hardecoded require statements, and still be able to receive upstream bugfixes. But I'll keep it in mind! – Thomasson

Answer 1

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.

Waggoner

+1 This sounded like a great idea when I read it in the question as well. The build system should build whatever the application needs from source elements, and a single unified properties file is a great source element. :) – Clougher

This is what we do too with similar layout (Symfony instead of Zend Framework). It's simple to implement, quite simple to maintain and fairly fool-proof. – Plummet

Thanks. This is what I implemented now. I did make it a conditional build element. Once built it will not be rebuilt (unless -Doverwrite is given) so people don't accidentally overwrite them. – Thomasson