I'm a php developer for a mid sized company that has only recently began to offer web solutions to its clients on its own, so we're in the process of building our team and setting up standards and the like.

We've made the decision to make use of the framework as a building block for all our applications but my project manager and I seem to have a bit of a disagreement on how to go about installing the framework.

I think the best thing to do would be to install it once on each of our servers, with the idea that all domains would then have the exact same set of features and functionality available to them. This would mean that applications developed by our team would be easily portable to any of our domains since they are all based off the same version of the framework. Upgrades to the framework from Zend would have to be reviewed and tested before deployed on the servers but with unit testing like phpunit, this process wouldn't be overly dreadful and relatively secure for each of the domains, (in my mind atleast)

My manager however suggests that we install a version of the framework for each application or domain so that upgrades can be done independently of other domains. I understand his concern for the public stability of the site but I think that the process of reviewing upgrades and unit testing would be more maintainable than trying to keep track of nearly 40 different versions of the framework and upgrading each one independently.

Now I could be wrong, but so could he so I was wondering what you would do in this situation?

how about the best of both worlds, install the framework in the php include path with a directory name like Zend_Framework_1.0.2. Then in each clients space you can create a symlink to the version that client is using. When a new version comes out install it in Zend_Framework_1.0.3 and update your symlink when your ready.

This way you can have multiple versions of the framework available to all clients with only one actual copy of each version. Each client can use any available version on a client per client basis. You can easily roll back to a previous version by updating they symlink again.

Now thats a great idea but one question, i'm not much of a System admin so how would to go about doing that in a virtual hosting environment? Can you create a symlink to a file outside the scope of that domain?

Thanks again for the help btw.

we run all our internal sites off the same server using vhost directives in apache

by putting the library in the php include path it will be available to all sites hosted by that server

We recently moved away from this solution however. What we do now is manage the Zned_Framework version through subversion. It works like so:

Each site has a subversion repository (svn://uri/siteA).
Since our sites all use a modular conventional FS layout (which includes a library folder parallel to the document root) we can easily attach a svn:externals property to the library folder and point it to the release tag of choice in the Zend repository.
When we need to update the version of ZF the site is using, we just update the svn:externals property and update to a development server where we can test and fix any issues. Once everything tests good we can update the live server via a svn update or switch to a new release tag for our site.

Tracking 40 versions of the framework could be really headache.

__________________
Affordable Web Hosting Coupons Free Domains
Hosting Coupons Promo Web Hosting Choices