On 8/11/2010 11:27 AM, Mark Steudel wrote:
Was thinking I could setup an infrastructure when a user creates a new vm for local environment, they register a domain name locally so that the rest of the network could access it.Yeah exactly it does seem like too much work just to look at a small bug. I use svn to deploy a lot of my sites to servers, it's super easy if you have command line access, and if you have control of your dns/domains it's easy to setup a bunch of various dev environments whether it's per developer, per project/feature etc.
So if I have my laptop but have two vm's running, one that is optimized for wordpress and joomla sites I work on, and another more advanced setup that is really optimized for Zend Framework based sites. Each vm would get its own static ip. I would then register *.paul.local so that any requests in the network would map back to my vm's servers, to make it really easy to access - sitename.paul.local.
This could also be useful for sharing a db resource with a few developer really quickly. To check to see if the error is caused by bad data, I could just update my application.ini db resource to use sitename.paul.local instead of localhost.
I'm not a system administrator but this is how, from my point of view, would be the most optimal setup - every developer gets their own local environment, but easily shared with the rest of the team.
On Wed, Aug 11, 2010 at 6:32 AM, Paul<z...@zooluserver.com> wrote:I thought about this, and this can be done. But it is also nice to be able to help another developer quickly, by actually viewing the site in a browser, especially when they are having an issue with frontend code. Currently, I manage a developer remotely, and he does do a php work, but does a lot of css work at the moment. Since he is still learning there are times where I need to see what the issue is, and the easiest thing to do is just look at the site firebug. Could have them have their own branch, have them commit the bug, the deploy the branch on my own local environment, but once again seems like a lot of trouble just see that a div has too much padding on it :) On 8/11/2010 9:23 AM, Саша Стаменковић wrote: If every developer have its own branch, he can commit to his branch, so you can diff with trunk, and see cnahges. Regards, Saša Stamenković On Wed, Aug 11, 2010 at 3:20 PM, Paul<z...@zooluserver.com> wrote:One more thing I thought of, was accessing a developers local environment. Currently, since we have everything on a shared dev server, I can easily look at the the teams code (great for the junior developers), and I can access their local copy of the site on a domain (site.paul.dev). Wondering if you do anything similar with your teams. Having each developer with their own local setup, definitely complicates this a bit. On 8/10/2010 3:44 AM, keith Pope wrote:On 10 August 2010 01:09, Paul<z...@zooluserver.com> wrote:Thanks Keith this is great! So for local dev, you let the developer choose their own environment. Or do most of your developers have the same setup (ie. all developer have a mac)?Thats right, we allow any environment and allow the staging server to detect the environment specific errors. Developers use Mac, Win and Linux plus most have VM's for testing. I believe the most important part of a teams setup is automation, this solves so many problems!On 8/8/2010 4:36 PM, keith Pope wrote:Hi, We use the following setup: Local dev setup (Development) Developers can use any IDE/Editor they like and can have their own LAMP etc setup. Ant - Used locally to configure, build and test the application (checks for dependencies etc) Data - Mysql weekly dump, sensitive data scrambled. DBDeploy - Used to version the database so everyone has up to date schema's Services (Solr etc) - Shared machine, available as VM Everything in SVN currently Dev build server (Staging/Testing) Custom application for quickly setting up versions of the software on the same server config as the live environment. This lets the developers checkout and setup vhosts for user testing/demos, integrates with the ant build system. PhpUnderControl (QA) Does all the continuous integration stuff we need... I would say our project is fairly large and I aim to allow the developers to setup a fresh install within a couple of minutes (minus copying the database) Currently to configure our application fully you need to do: ant refresh-properties ant ant apply-db-changes (if there are deltas waiting) Takes a couple of minutes, the main thing here is to automate as much as possible, this makes dev, testing, integration and deployment much easier! On 8 August 2010 11:32, Wil Moore III<wil.mo...@wilmoore.com> wrote:Thomas D. wrote:Maybe you are using other services like "Sphinx" for search. Should every developer run and maintain a copy of Sphinx?You should be able to get away with running one of these on the dev machine. Just replicate over from prod periodically and have each developer hit this instance. It is less likely that every developer needs his/her own search server. Thomas D. wrote:- Maybe you are working on an intranet application, which requires authorization. You will authorize against a LDAP system. Should every developer run and maintain a local LDAP service?I haven't approached this regarding LDAP so I can't comment. Thomas D. wrote:- In real applications, you will have multiple entry points (website, API access...). Do you think every developer can run and maintain these things locally?Assuming this is all in your scm and deployed the same way, I see no reason not to have all of this working on each developer's instance. We run the main web application, public api, and cli scripts from the same Zend_Application instance w/ Zend_Config. You don't need ZF to do this but ZF makes it easy and organized. Thomas D. wrote:Your dummy data may also run out of dateI suggest a weekly dump, but depending on your app, dummy data may suffice. Sorry to say it, but, it depends. Thomas D. wrote:Maybe your application is a shop system, your data contains credit card numbers and other sensible information. Do you want that every developer has access to these data? ;)Are you really storing the full credit card number? If so, the dump isn't the problem. You aren't PCI compliant in this case. Last 4 is OK. Even with that, I don't see the need to transfer the real last-4 numbers to dev instances. Those can easily be mocked. This is a good reminder of why I'm glad I no longer deal with e-commerce data. Thomas D. wrote:- Logging. Your application will generate many log files.Syslog is your friend and it is available by default. With ZF, you can switch between logging to syslog/file based on environment if you like; however, I like syslog. Thomas D. wrote:But you won't want that your developers sends out test mails to real users.Filter the email address to be an internal one before sending or write a mock smtp adapter that simply logs the intended recipient and the email as it would have been sent to a file. Thomas D. wrote:Should every developer run and maintain a local mail server?Not if you take the above advice. ----- -- Wil Moore III Why is Bottom-posting better than Top-posting: http://www.caliburn.nl/topposting.html -- View this message in context: http://zend-framework-community.634137.n4.nabble.com/Team-Development-tp2316451p2317664.html Sent from the Zend Framework mailing list archive at Nabble.com.
