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 <[email protected]> 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<[email protected]> 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<[email protected]> 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. >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> >> >
