dl__
dl__

Reputation: 4610

How to best update a website from subversion

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.

Upvotes: 5

Views: 7339

Answers (10)

Mauro
Mauro

Reputation: 4224

Have you checked out Beanstalk? http://beanstalkapp.com/ It's a SVN/GIT server and it features automatic FTP deployment.

Upvotes: 0

Mike
Mike

Reputation:

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

Upvotes: 0

Jason Kealey
Jason Kealey

Reputation: 7996

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)

Upvotes: 2

Luke
Luke

Reputation: 21286

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.

Upvotes: 1

Davide Gualano
Davide Gualano

Reputation: 12993

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.

Upvotes: 6

Anders Sandvig
Anders Sandvig

Reputation: 20986

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).

Upvotes: 1

Lucas Oman
Lucas Oman

Reputation: 15882

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.

Upvotes: 0

Bell
Bell

Reputation: 18705

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.

Upvotes: 1

Ken Liu
Ken Liu

Reputation: 22914

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.

Upvotes: 4

sebagomez
sebagomez

Reputation: 9619

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

Upvotes: 1

Related Questions