Re: Site management strategies with Subversion
Re: Site management strategies with Subversion
- Subject: Re: Site management strategies with Subversion
- From: email@hidden
- Date: Mon, 13 Mar 2006 13:53:19 -0800
Thanks, Zak. I follow you, but I'm still confused about one thing.
How are you creating the source directory, the one being accessed by
APP in your release.sh script?
In the CVS world, one could tag and then export, like you said, and
you might tag only a subset of the files that have actually been
committed since the last release. But in the Subversion world, with
it's atomic commits, it seems that it's going to be an all or nothing
thing - any tag or export is going to include all commits. Is it
possible to follow the process you're describing and yet not include
the changes made to a particular framework? Because that one is not
quite done, but these other changes over here have to go live right
away?
It appears that in Subversion that's not possible unless the code for
a project is broken up into multiple repositories, one for each
logical unit. Maybe that's the right thing to do?
I hope I'm making myself clear; if not, let me know and I will try
to come up with a concrete example.
thanks,
janine
On Mar 13, 2006, at 1:32 PM, Zak Burke wrote:
email@hidden wrote on 3/13/06 3:25 PM:
Something I do frequently is push small changes from a dev site to
a live site. In CVS I do this by tagging the files in the dev
site I want to move over with "stable", then going over to the
live site (which was originally created by checking out on the
"stable" tag) and doing a "cvs update".
A former sysadmin wouldn't put CVS on her production boxes. "CVS is
a development tool. Production boxes aren't for development," she
said. Our process was to "cvs tag", then "cvs export", then build
in a directory like "some_app-1-0-3". Then we'd make a tgz archive
to copy to production. Our deployment directory looked something
like this:
$ ls /var/httpd/cgi-bin/
some_app -> some_app-1-0-3
some_app-1-0-3/
some_app-1-0-3.tgz
some_app-1-0-2.tgz
some_app-1-0-1.tgz
some_app-1-0-0.tgz
That made it really easy to update production -- we'd just push out
the archive, expand it and then point the app's directory at the
current release like this:
ln -sf some_app-1-0-4 some_app
If there was a bug and we needed to rollback to an earlier version,
this was very easy too. My current production environment is not so
strict, but I've stuck with this way of doing things because it's
served me very well.
With a few simple shell scripts and an ssh key, it's very easy to
automate the entire process, and then it's just as easy as running,
"cvs update". I'm sure you could do this entire thing with ant.
Failing that, however, here is a bare-bones shell version:
#!/bin/sh
# usage: ./release.sh <app-name> <tag-name>
# app to deploy, e.g. "foo.woa"
APP=$1
# release tag name, e.g. "foo-1-0-4"
TAG=$2
# server to deploy on
SERVER=some.server.com
cd dist
cp -R $APP $APP-$TAG
tar czf ../$APP.tgz $APP-$TAG
rm -rf $APP-$TAG
sftp -b /path/to/release_sftp.sh $SERVER
ssh -i /path/to/id_dsa $SERVER "/usr/local/bin/deploy.sh $APP
$TAG"
release_sftp.sh is just an sftp put command into /tmp/. The remote
deploy.sh script just unpacks and redirects the alias:
#!/bin/sh
APP=$1
TAG=$2
FILE=$APP.tgz
DIR=/var/webobjects/
echo "extracting $FILE..."
cd $DIR
tar xzf /tmp/$FILE
chgrp -R appserverusr $APP-$TAG
chmod -R 775 $APP-$TAG
echo "pointing $APP at $APP-$TAG..."
ln -sf $APP-$TAG $APP
echo "done"
zak.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden