views:

1513

answers:

9

I have a PHP website backed by a MySQL database and a small team of programmers submitting code to subversion. Typically we write code, test it locally, commit to subversion and then copy changed files to a hidden area for online testing.

However mistakes can be made. Occasionally I want to refresh the site so that I know, without a doubt, that the site code and database really represents what's in subversion. I'd like to get as close to a one click solution as possible so that it's foolproof.

What's the best way to do that?

BTW, if it matters, we develop on windows machines.

+1  A: 

What about checking out the code to place where you want to run it from?

sebastian
You would probably be much better off "exporting" the code to where you want to run it, so you don't have all those .svn folders lying around on your web server.
Kibbee
+2  A: 

I wouldn't recommend checking out your code to your production server. This can potentially expose svn control files (.svn) on the server.

I would recommend using a script (python, ruby, etc.) combined with the command line svn and FTP client to export the files from svn and ftp the files to the server. The svn export command can be used to check out a set of files from the svn server without all the .svn directories. Also, don't forget to tag the svn repository when doing this so you have a checkpoint of what you have deployed.

Ken Liu
You can use 'svn export' to "check out" a clean directory without the .svn folders.
Anders Sandvig
A: 

Code version management and database version management are two very different problems. The solution that I prefer is done in three stages (Test, Deployment Test, Live) rather than two.

  • Update the code and apply database changes via scripts in the development environment
  • Download the live database to a deployment test environment, restore it and apply the change scripts
  • Test the code against the 'synchronised' live database
  • Update the live environment via svn from the relevant branch on the repository (we do it via ssh tunneling since it's a linux environment) and apply the change scripts to the live db

Edit: The update for the live environment is best done using export rather than checkout/update. This doesn't leave svn's control file hanging around. This may or may not have security implications, it does force you to specify which branch you're checking out each time though.

Your 'one click' could probably be scripted for the last step.

Bell
A: 

I would recommend:

  • copying each old build to its own directory (for quick restores; you probably only need to keep one of these) in a non-web-accessible part of your server.
  • Then use svn export to get the entire new build from svn. Don't use svn checkout, as this will leave .svn directories all over the place.
Lucas Oman
+1  A: 

If you install the Subversion command line client, it's quite easy to make a batch file/shell script that will do a checkout export of the latest revision from the repository to a folder on the server. This requires that you have the same file structure in Subversion as you do on the server though (unless you want to add the logic to change the structure in the script, of course).

Anders Sandvig
+3  A: 

The export can be automatically done after every commit with a post-commit hook:

http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.post-commit.html

You can setup the hook to automatically export the project inside the hidden area for the online testing.

Davide Gualano
A: 

I recommend that you write some sort of script that does this for you. Whether you do this with PHP or something else is up to you. Just keep security in mind when you do this.

Doing an export of your project won't export any svn:externals you might have set which means you need to do multiple exports. When you script this it shouldn't of course being much of an issue. Another thing with exports, if you project is large (if you use lots of video, PDF's etc.) then an export can be quite cumbersome, especially when your version control is hosted off-site and only available through HTTP.

I recommend you do a checkout and make sure that your server can't serve any files located in the hidden .svn folders.

Luke
+1  A: 

We deploy via Subversion and use database migration tools (with schema versioning) to do this.

(http://blog.lavablast.com/post/2008/02/I2c-for-one2c-welcome-our-new-revision-control-overlords!.aspx)

(We develop in .NET)

Jason Kealey
A: 

Thanks for all the answers, helped a lot to proof I wasnt doing too wrong. We're developing and testing on a local checkout of a online subversion repository. When we want to deploy a new version we run a script which basicly deletes the current export on a live testserver, creates a new export and then deploys to all webservers via rsync.

Problem with this: Rsync always copies all files when deploying to the liveserver because of the completely fresh export. I actually never took the time to find out how to update an export.

On another machine I just have a checkout and deploy with rsync --without .svn