[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS in web development environment

From: Laurent CHARLES
Subject: Re: CVS in web development environment
Date: Tue, 20 Jul 2004 17:06:14 +0200
User-agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5) Gecko/20031120


Ian Michell wrote:
We are currently thinking of migrating to CVS for all our development.
It is fine for java development with multiple devlopers as we can
compile the code in our own sandboxes. But on the web development side
it is a little trickier with multiple developers as we have one
development server that is used for testing, and everyone currently
tests and develops out of the same directory.

One way of sandboxes this, is to allow the developers to checkout into
thier own home directory (on the development server).

Our main problem is we have over 100 virtual hosts in the apache conf
file pointing to our development server, therefore we need to find a
way to allow each developer to make use of these virtual hosts, and
develop and test out of their own sandboxes.

Are there any ideas, or any common ways to solve this problem?

I don't know if there is a common way. We manage some similar issues with web applications, not with as many virtual servers though. Here is a attempt to give you some ideas of simple principles we try to respect.

To simplify, we can consider we have 3 types of files to manage in an application;
- Sources
- Configuration
- Data

The sources are simply managed with a classical repository. Checkouts, updates, merges, etc. are the everyday life of the developpers in their sandboxes.

The configuration files are managed the same way if they apply to all machines and services. If conf files can not be applied to all machines (like 'httpd.conf' for ex), we either use one conf file per machine (eg 'httpd.conf.machine'), and soft links it(*) to the ad hoc file on every machine, or we have a process to generate it from a template.
(*) the developers can also start the service specifying the conf file.

We may have a Makefile in a "main" directory with a rules such as 'update'. Thus, 'make update' runs for example, a 'cvs update' in every directories (eg: /etc, /var/www, etc.), and may run some processes as well (e.g create links, generate config files).

Managing data is more complicated. I mean data that can be considered as application sources (initialisations for ex), not users' or application data. We try to manage them with scripts under control (for example sql scripts to run to initialise a database). A similar 'make update' process may be used if relevant.

On the server side, developers have usually their own server running one instance of the application, based on their current sandbox sources. It is also possible to run several instances of the application on the same server, each based on its own set of sources and configuration files. This might be interesting when tests require the usage of a single database.

With such structure of our works, we have a pretty good control of the whole application, and can setup very quickly a new developping environment based on any version of the application.

Hope it helps.
I'm interested in any feedback people can give.

Another comment... Sorry to post it here...
Why CVS? Why not starting with Subversion or Arch?

-- Laurent

reply via email to

[Prev in Thread] Current Thread [Next in Thread]