[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: live and dev servers - best practices questions

From: Mark T. Dame <mdame_at_mfm.com>
Date: 2005-11-10 16:53:54 CET

Andrew Brosnan wrote:
>
> I'm joining a project that is set up as follows:
> * a development server (web and database)
> * two load balanced 'live' web servers
> * two database servers - (master/slave)
> * an offsite 'failover' server - (web and database)
>
> Currently things are a mess because data that should be specific to each
> running version is included in the lone branch in the repository; so for
> example, an update of the code on the dev server will result in the dev
> server trying to connect to the live db rather than the dev db.

Sometimes simpler is better: we use the server name 'masterdb' in our
code. Then in the /etc/hosts file on each machine, we set masterdb to
the correct database server. On production this goes to our main
database server. On our development server(s) it points to localhost
(since the development database server runs on the same box as the
development web servers).

> The code running both live (and dev) servers are working copies. I'm
> told that this was done for the ease of just being able to run 'update'
> after changes, thus updating the live (or dev) server(s). What do people
> think of this? How do others ensure that your code is up to date in
> cases where the code needs to run in multiple places?

We do exactly this on our production servers.

-m

-- 
## Mark T. Dame <mailto:mdame@mfm.com>
## VP, Product Development
## MFM Software, Inc. (http://www.mfm.com/)
"A brute force solution that works is better than an elegant
  solution that doesn't work."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 10 17:18:09 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.