tags:

views:

52

answers:

2

Question on how to go about pushing out our PHP code. Previously, we would simply run our test suite, commit changes, and then svn up on the productions servers to "push" out changes. I'd like to change this because I'm not too comfortable having svn on the production servers for multiple reasons.

I was thinking of just writing a script that does the followings: (would push out from svn server)

  • svn export
  • Tar and scp new code to production servers.
  • ssh to production servers and unpack archive

Obviously overwriting all previous files in the process/cleaning up.

This would be speedy. Any bugs could easily be fixed, committed, and then just re-push the code back out to the servers (or revert a revision, etc). Any comments/suggestions/criticisms to this approach are appreciated. ;)

+2  A: 

Exactly what Capistrano does and what I use it for. It's designed for Rails apps, but is easily customizable, with the railsless extension taking care of most parts for you already. It's written in Ruby, but is easy enough to learn.

deceze
If they haven't complex build scripts (and they haven't) what is the reason to replace simple and trivia `svn up` with Capistrano, which needs to be set up and supported? ;-)
zerkms
@zerkms Depends on what you mean by "build scripts". You can script Cap to do anything you want before, during or after deployment. And that's the key, because usually you're not done with a simple `svn up`, you usually want to clean tmp files, migrate databases or do system specific tasks as well. Cap can be automated to do all that for you.
deceze
@deceze: I've based my answer on the OP's mentions: it is something about "more control" and "secure". Well in that point of view - svn is the best candidate ;-) Anyway, I'm not against the deploy tools, I'm just curious why people like to make the things more complex than it should be ;-)
zerkms
@zerkms To securely set up "svn deploys" is about the same amount of work, since your svn server needs to be securely accessible from the outside world in some fashion (depends on your setup obviously). Push deploys OTOH only require a remote login to your web server, which you need anyway. I used to be an "svn deploy" fan as well until I tried Cap. Now I'm not going back. :)
deceze
Nice argument about securing svn server.
zerkms
@deceze, Spot on with why I'm moving away from just doing svn ups. :)
Magic Hat
+1  A: 

In our local environment, I had set it up so that when code was committed to trunk (meaning tested, stable code that's ready for web deployment), I had a shell script as the post-commit hook to manage the changed files via FTP.

I'm sure there's much better managed solutions, but that was easiest for me.

Codeacula