Whats Your Development Env. ?

Carl Forde cforde at stormlantern.ca
Tue Jan 20 22:49:02 UTC 2009

Blake, here's how we do it:

each project has a separate set of code trees:
eg. svn://host/project/trunk , svn://host/project/tags ,
each developer has read/write access to the projects they're working on

Development: (developers only)
dev server has its own database server
each developer has an account on the dev server and checks out the
code repository into their own file space which is accessed via sftp
and ssh
I use MacFuse to mount the directory on my Mac so I can use TextMate
etc, others login and use vi to edit their files (they could just as
easily use vi on their Mac or whatever suits)
eg. svn co svn://host/project/trunk /home/developer/www/project
apache has virtual host entries for each developer & project like this:
http://project.developer.dev/ maps to /home/developer/www/project

this way every developer can work independently of every other
developer and everyone else

Test: (developers & testers & other interested people)
test server has its own database server
projects are checked out into separate directories in the web tree
eg. svn co svn://host/project/trunk /home/apache/www/project
apache has a virtual host entry for each project like this:
http://project.test/ maps to /home/apache/www/project

this gives testers and others a stable environment for their use
it can be updated as needed or on a predictable schedule appropriate
for each project

Production: (public facing)
production servers share a single database server
set up like test with host names changed as appropriate

Development work is never done on live. All changes start on dev, are
commited to svn and migrated through to live.

Some advantages: all code stays on managed servers, database accesss
can be secured to the appropriate servers, developers can work
completely independently (possible exception of some database
changes), developers don't have to worry about apache
configuration/administration, consistent development environment for
everyone, developers don't have to worry if they have the right
modules and versions required

Some disadvantages: dev server has multiple copies of the code base,
some additional apache administration to set up the virtual hosts on
dev, assumes a formal arrangement with each developer

Alternatively, each developer could set up their own database and
apache server, check out the code base onto their own machines and
test locally. For FOSS appilcations, this is probably the better
choice. It sounds to me like you're missing the 'test locally' part.
If you're on a Mac you might be able to use the apache environment
that ships with it. If not, you can probably update apache etc to the
required version levels. If you're doing some low-level system stuff
that might not be good enough. If you're on an Intel system you could
use VMWare and install an appropriately configured LAMP stack. If
you're on Windows, you will almost certainly have to do that.

Hope that helps,

On Tue, Jan 20, 2009 at 1:14 PM, electBlake <electblake at gmail.com> wrote:
> Calling All Code Junkies!
> Blake here, from the VULab project and I'm having problems figuring out a
> good way to setup my development workflow.
> My Preference.
> I enjoy working on a live development server so I can fully see how my php
> code is going to behave on a standard LAMP situation, as such I also enjoy
> using an integrated ftp code writing client.
> The Problem.
> York University, where VULab is hosted is like many other private and secure
> server clusters that don't allow the ftp protocol to be used to access their
> servers. The sftp option falls short as with my current permissions I need
> to sudo <cmd> to have write access.
> The Current Situation.
> Currently I am biting the bullet and I am developing the site locally, and
> then submitting my patches to svn and after the patches have been committed
> I ssh into the server (vulab.yorku.ca) and checkout the latest from the svn.
> This works but like I stated in My Preference, I enjoy seeing my code on the
> final server setup asap.
> The Solution(s)?
> I am curious as to how you other fluid'ers are developing and what your
> workflow is. Be as details or straight forward as possible. I am new to
> working within a svn workflow so I feel like I am missing something.
> Thanks!
> - Blake
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

Start by doing what's necessary;
then do what's possible;
and suddenly you are doing the impossible.
-- Saint Francis of Assisi

More information about the fluid-work mailing list