Re: CVS in web development environment

[Laurent CHARLES]

Hi,

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