views:

673

answers:

2

I am using a development, staging, production server environment with some other developers.

Right now we make changes, test them on our dev server(personal computer) then once we are happy with the changes and want to show them to the client or internal review we commit the changes to repository and update the staging server's working copy via samba(tortoiseSVN) or ssh.

This gets really tedious and repetitive. I am looking to have an post-commit hook update the remote staging server but the only options seem to involve hard coding a user creds in the hook for SSH or creating a network mount with a user account. Is there a way to pass the user authentication from the initial commit to the staging server to update or any other suggestions?

Other setup solutions welcome.

+1  A: 

Did you consider using an automated system like CruiseControl (http://cruisecontrol.sourceforge.net/) on your staging server?

CruiseControl can be configured to check if there are new checkins and then start a build (that usually does a checkout as it's first step).

You can even monitor different branches and do automated integration and release builds depending which branch got changes checked in.

We use that idiom very sucessfully here for our automated builds.

lothar
Thanks for the suggestion I will keep that in mind. It may be a bit much due to no build/test parts to our process and I was hoping to do an svn update so that less files have to pass across the servers and the people reviewing the staging server would get more instant results after our commit
joelpittet
+3  A: 

If you are worried about hard-coding user SSH credentials into your script, you can create an SSH keypair without a password. On the destination machine, you will want to restrict that keypair to only run Subversion by adding

command="/path/to/svnserve -t"

to the front of the SSH authorized keys file, like:

command="/usr/bin/svnserve -t" ssh-dss <key text>

Modify your hook script to use this key for login, and you will have (slightly) more security than a traditional no-password SSH key.

Tim Whitcomb