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.
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 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. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> > > -- ----------------------------------------- Mark Steudel P: 425.298.7244 F: 206.260.3021 msteu...@gmail.com . : Work : . http://www.mindfulinteractive.com . : Play : . http://www.steudel.org/blog
