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

Approach to a Website Staging/Production Environment

From: Tilmann Singer <tils_at_tils.net>
Date: 2006-02-10 12:55:03 CET

Hello List,

I would like to set up an environment for website development where
most of the time the development happens on trunk and developers can
flag individual files as ready for a staging server or ready for
deployment on the production server.

This kind of problem has been discussed before here
http://svn.haxx.se/users/archive-2004-12/0824.shtml
http://svn.haxx.se/users/archive-2004-12/1420.shtml
but I couldn't find an answer to my specific question.

In CVS it was easily possible to set a tag for 'staging' and
'production'. For example when a certain subdirectory of a working
copy of the code was ready for staging, one could cd to that
subdirectory in the working copy and do a "cvs tag 'staging'" to
promote the staging tag for only the files within that subdirectory. I
want to be able to do that only for specific subdirectories or files,
without affecting other areas of the project, because there might be
experimental development going on by me or other developers that is
not yet ready for staging or production.

One possibility to achieve this functionality in subversion would be
to use one branch for production and one for staging, but in my
understanding it would require to manually merge desired changesets
into those two branches each time one wants to move a change into
staging or production, and tracking somehow which changesets have
already been merged. It implies the danger of forgetting to merge a
changeset. My gut feeling to this approach is that it would become
somehow messy, and too much administration for our limited resources
and svn experience.

So I had the idea to replicate the cvs tag functionality in the
following way:

Create a special file for each tag, deploy_list.staging and
deploy_list.production, which control the revisions to be
deployed. Each line in those directories contains a path below trunk
and the associated revision. For example it could look like this:

/ 251
/some_sub_dir/ 275
/other_sub_dir/ 289
/some/special/file.php 311

Based on the contents of such a file I wrote a simple script that
produces a svn export with the specified revisions for deployment on
the staging and production server. It sorts the entries so that the
least specific are exported first and proceeds to export the more
specific. Before doing an svn export for an entry it does 'rm -rf' on
that path to make sure that file deletes in the later version are
being correctly exported.

The developers will have to use svn info to find out what version
their local checkout is at and edit the deploy_list files to tag their
changes as staging or production ready. I think that this will be less
tedious and less dangerous than dealing with branches. Experience will
show how it works out.

Did anyone try something similar already? Any suggestions, estimates
if this would work or not and why?

regards, Til

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 10 12:56:33 2006

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