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 date >>>> >>>> >>> >>> I 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. >>> >>> >> >> >> > -- ------------ http://www.thepopeisdead.com