Right now, the current deploy process at my work is based around tagging from the trunk and switching various PHP web sites for clients on our QA and Production servers. While this is simple from the technical level, it becomes really tedious when you have over a dozen updates to a dozen different sites that need to go out in one day.

Towards this end, I'm implementing the following stack:

  • SVN
  • Hudson
  • Capistrano

And it will work like this:

  1. Code goes into svn
  2. svn post-commit hook triggers hudson
  3. hudson runs a capistrano script to deploy to the dev server
  4. project managers check out the dev server, and if the bug is fixed, they go into hudson and promote the build
  5. hudson runs a post-promotion script which tags and deploys the code to whatever server is specified by the promotion

Capistrano (along with the symfony framework) will be used to migrate the databases.

Am I missing anything here? I've never done anything more complicated than subversion before, so that's why I'm asking.

  • There should be also one missing part: run the tests :) (if you have some). Also migrate the database, run bundle, compile assets, etc... Commented Dec 9, 2011 at 23:20
  • Yeah, I'll be using capistrano to handle the migrations, bundling, etc. There's no unit tests (yet) since we're still trying to spec out common functionality for all of these websites
    – CamelBlues
    Commented Dec 9, 2011 at 23:25
  • 1
    Well, if you are standing this up from scratch, you might want to upgrade to something better than SVN while you are at it . . . Commented Dec 10, 2011 at 0:02
  • Why does everyone hate on SVN?
    – CamelBlues
    Commented Dec 10, 2011 at 4:01
  • @CamelBlues centralized version control is not in fashion these days.
    – user1249
    Commented Dec 10, 2011 at 7:34

3 Answers 3


One big thing is missing -- how do you roll back if the build fails? Especially, how do you snap shot the database before deploying?

I'm not horribly familiar with Capistrano so it might cover this. But a quick read of the project page doesn't indicate that it does.

  • Capistrano allows you to run Ruby Migrations, which are reversible (although that comes with a risk of data loss).
    – pdr
    Commented Dec 10, 2011 at 2:16
  • 1
    Well, he is running PHP though I guess one could still use ruby migrations there. And you do note the data loss issue which is paramount. Commented Dec 10, 2011 at 3:35
  • Ahh-- that is a very good point! All the PHP is the Symfony framework and the Doctrine ORM, which will allow me to roll back any schema changes--but I didn't think about lost data!
    – CamelBlues
    Commented Dec 10, 2011 at 3:57
  • 1
    @WyattBarnett: Thing is that you almost never get rid of data on an upgrade. At least not without having it backed up somewhere. The risk is on downgrade; customers may have entered data into a field you just added and might not be happy if you downgrade and lose it, then upgrade with a fix. But that's a fairly uncommon case and not worth worrying about until you decide that rollback needs to happen. Likelyhood then is that you just remove that field from the downgrade path. It is rare you'd have to be more clever than that.
    – pdr
    Commented Dec 10, 2011 at 17:32
  • 1
    @pdr -- what about when your upgrade is writing bad data? Or deleting good data? The only valuable part of your system is the user's data. Treat it like gold. Commented Dec 12, 2011 at 18:40

I had almost exactly the same question recently, and I came across this book:


It is aimed at PHP, but a lot of the processes it describes can be implemented (albeit in similar but slightly different ways) in other languages!

I would say this is a must for any serious developer / development team.


Continuous Delivery is a book you should read. But I think you'll find the main advice you'll get from it matches the advice you've had in comments: Use a DVCS instead of SVN, and get your test coverage (unit and integration) sorted out.

I would add to that, use Jenkins instead of Hudson. Oracle now own Hudson and Jenkins was branched from it just before they took over. The open-source support from a very engaged community is likely to out-strip Oracle's support pretty quickly.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.