Working with Zend Tool in multiple dev environments

On any given Zend Framework project I can be working in 2 or 3 locations - my work PC, home PC or my MacBook. My source code is always in SVN and I usually work on a development server before pushing completed work to the production server. In this kind of environment I've never been too sure where exactly I should work with Zend_Tool.

How i see it, there's 2 options:

1. Set up to work locally with Zend_Tool on each dev environment and then push to dev server from there, checking in the manifest etc with each Zend_Tool usage.
2. Use Zend_Tool directly on the dev server and then download each addition/alteration to then push into SVN.

开发者_如何学编程

I would be inclined to say the most reliable way would be the multiple Zend_Tool setup but i'd be interested to hear if people can think of any potential issues with this or reasons why i should make a different choice.

Thanks.

---

Zend_Tool is actually intend to use on the Development environments. Your feeling about using it on multiple places is quite right, actually, the only problem is the sync between the XML that Zend_Tool uses to know different configuration on the project, and yet, this would only happen if major changes are made during the same revision on different working copies (common version control limitation/problem/whatever).

Other than that, you should't have any problem at all.

---

Zend_Tool hard codes the APPLICATION_ENV to 'development' in the file Tool/Project/Context/Zf/BootstrapFile.php

You could get all reckless and change the source code (not a great idea, but it will work). Applying this patch will allow you to use an environmental shell variable to tell Zend_Tool what env you are in.

    --- BootstrapFile.php (saved version)
    +++ (current document)
    @@ -106,9 +106,11 @@
                     define('APPLICATION_PATH', $this->_applicationDirectory->getPath());
                     $applicationOptions = array();
                     $applicationOptions['config'] = $this->_applicationConfigFile->getPath();
    +                
    +                $env = getenv('APPLICATION_ENV') ? getenv('APPLICATION_ENV') : 'development';

                     $this->_applicationInstance = new Zend_Application(
    -                    'development',
    +                    $env,
                         $applicationOptions
                         );
                 }
    ,

Just remember to set an APPLICATION_ENV environment variable.

Needless to say this is quite dangers and could blow up if you have the wrong enviroment variable set, but for those of us using ZFDoctrine that integrates Doctrine commands into the Zend Tool, we don't have a lot of other choices when it comes to doctrine migration.

See this reference http://framework.zend.com/issues/browse/ZF-9898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel

---

What we do here at my work is create an instance config. By doing this we have 3 configs depending on what environment the application is running in.

1. Local machine (debugging while programming).
2. Development (used for testing our code before pushing to production).
3. Production (Live environment).

We then setup the config class to load the configuration which has the paths and data for our tools based on what environment we specify in our config file.

Basically we have a file called Chooser.txt which will have in the file the filename of the config file for the environment to run. When we want to run it locally we edit the Chooser.txt file to local_config.txt (we use .txt so we can eval certain configs and we then .htaccess the config directory so no one can view it). When we push to the dev server we then edit Chooser.txt to say dev_config.txt and so on. Then in dev_config.txt or local_config.txt we will have the config variables for the tools and the php settings etc...

Now with this said we install the tool in each environment so we will have our tools and libraries in our local environment, dev and production. By having our tools in a localized environment it makes it a lot easier to do testing when updating / patching tools so that you are not just patching the tools on the production server when you should be testing them on the dev server first.