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.
>



-- 
------------
http://www.thepopeisdead.com

Reply via email to