Strategies for upgrading webapps?
Calling all software developers! Garrison and I need some help...
Here is the scenario. We have to maintain a bunch of production web applications, most of which use Zend Framework. When we have created a new version of the application, we need to deploy it to production in as simple of a way as possible. We have automated the file version of this by using Phing to export the tag out of SVN, copy old config files, set write permissions in the correct place, etc. However, the database manipulation has happened manually and we are looking for strategies on how to automate this.
We came up with an idea to write a custom migration library which will execute php and sql files, but it seems like a problem that has to be solved better by someone else. Anyone have any tips? Anecdotes? Strategies? Anything to help us get going in the right direction would be much appreciated. I'd even buy someone a beer or two
January 13th, 2010 - 15:44
I’d take a look at dbdeploy or LiquiBase if you haven’t already. I’ve experimented a bit with dbdeploy but haven’t tried LiquiBase yet. There’s a dbdeploy task in Phing which could help quite a bit.
January 13th, 2010 - 15:51
We looked at dbdeploy, and it will take us half way there I think. While versioning the schemas is a step in the right direction, we also have an issue where some type of manipulation of the data in the database is needed. For instance, if you have a table with an attribute of phone_number, but in the next version you need to pull that attribute out so n amounts of phone numbers can be assigned to a user. You need to copy all the data from the existing field into the new table, then drop the original column, all while maintaining keys. Will dbdeploy help with that?
I guess I am trying to get my head around doing this without having to use PHP to do some kind of magic.
January 13th, 2010 - 15:56
I don’t have a lot of experience with dbdeploy, but my understanding is that you just write SQL scripts so you could have both DDL (e.g. CREATE TABLE…) and DML (e.g. INSERT INTO…) in these scripts. Ideally you’d write both an UP and DOWN version of each script so you could do rollbacks too.
January 14th, 2010 - 14:31
I’ve been struggling with much the same situation with web2project upgrades. Managing the database – especially in an engine-agnostic way – is a pain. At DCPHP last night, someone suggested that the app itself might not be the place for it and suggested that Rails might be a good fit.
It’s not a good fit for us – the app is open source and we have no knowledge/control of the configuration – but it might be an option for you. There’s no reason that *everything* has to be 100% PHP all the time.