Firstly apologies for not authorising your comment for so long, it went unoticed in all the spam

Our system is built entirely in Perl except for the integration with subversion for checking out code. It sounds like you are going to use the hooks built into sv, we considered that as well but wanted to avoid the use of ftp or sftp and also have a bit more flexibility than it could provide. If it works for you though then don’t let me know persuade you differently

If you are going to deploy changes / updates, what happens if you want to go back 4 versions, will you be able to do this or would you have to rely on this process being done manually? I highly recommend the automation of deployment, it makes so much sense and allows a lot more time to be spent on the development / coding aspect of things rather than how and when you will update your site or code.

Neil

I’m looking to take the first step with my development team, i.e. simply automate an FTP upload based on a subversion export of a certain tag (i.e. release-1-1) or a branch for bug fixes (i.e. maintenance-1-1). Of course, it should only deploy changed files/folders, not everything.

I like the looks of the CI stuff, but I think something more simple like Ant would be a good starting point, while I/we learn the ropes. Any thoughts/comments?

At the moment we are lucky enough that we don’t actually store a lot of data in our DB’s but we do rely on them heavily, changes to the schemas are done on a dev system first, then rolled out to a test environment before being deployed into live systems – all done manually.

If I had to implement a system to automate the deployment for DB schema changes then I would still have changes made to the dev systems done manually. Both the testing and live DB’s would be load balanced with at least two master db servers behind each VIP. When the system marks the updated schema for release, a db server behind the test VIP would be pulled out of service, the schema updated and then a test copy of the site or application would be tested automatically against the updated schema. If any tests fail then the db server is kept out of service to be either fixed, have it’s schema altered back or have the data resynched from another server so it can be brought back into service. If the tests succeed then the db server is put back into service and the remaining db servers are removed for the schema to be altered. Rinse and repeat for production db servers. You’d have to keep a track of what schema version each db server is currently running without replicating that info out to all of the other db servers but that should be simple enough.

I’d love to be able to have a crack at this but our usage just doesn’t warrant the work involved at the moment

This is interesting, but I’m wondering how you deal with significant schema changes that need to go out? As noted in Timothy’s article, their system isn’t much more agile than anyone else when altering a table with millions of rows, and I’m wondering if you’ve done anything interesting there.

Thanks for the article.

–Bruce