Page 2 of 2
Posted: Tue Apr 10, 2007 9:04 pm
by bpopp
Updates should always be pushed to the user in my opinion. Relying on a site to get a certain number of hits before it checks for an update is too risky; it might be a quiet site with a huge security issue.
I second that. SVN works quite nicely for deployment. If you're not using it, you should be. It changed my life. It's better than Tivo. You just import your project into SVN and then check it out in various places. I check out a copy in my development folder, my buddy checks out a copy on his development folder, and then we check out another copy on the production server. He makes a change, commits. I update(which pulls down his changes), make a change, and then commit. Once we've tested and feel comfortable with the changes, we go to the production server and do a simple 'svn update'. All changes are incorporated. If we later realize that we broke something, we can go back to the production server and do a quick revert to put it back the way it was one version ago (or several).
Unless you're using an advanced ORM, obviously this won't sync up your database structure, but Navicat (for MySQL) has a really nice Data/Structure synchronization tool. It will mirror two database structures (and optionally data). It's commercial, but is very reasonably priced IMHO ($100 or so) .
Posted: Tue Apr 10, 2007 9:22 pm
by dreamscape
I use, what I think is a rather simple system, but it works quite well...
What I do is create an SVN diff of old revision vs. new revision. Then I have a simple script that reads the diff, and given a clean copy of the new revision of the application, will create an update "package". The "package" is basically a serialized array of instructions (add, remove, or update) plus compressed versions of the files that need changed or added.
And if needed, on top of the update "package", a pre-flight script and post-flight script can also be written (in here is where I place db changes)
Then I have a PHP CLI updater script that resides where the applications are installed. All I do is place the update package (named update.package) and any pre-flight or post-flight scripts in the appropriate location, e.g, cli/updater/1.1.0-to-1.1.5/, and run the update script, e.g, cli/updater/update 1.1.0-to-1.1.5. The update script then runs the pre-flight if it exists, runs the instructions in the update.package, runs the post-flight if it exists, and then if there are no errors or problems, it is self-cleaning and will delete the package directory, e.g. cli/updater/1.1.0-to-1.1.5/...
And that's it basically... a "self" updating application without much fuss... it makes updating several applications quite easy. I don't automatically publish or look for updates, but of course that would not be difficult to add.
Actually it sounds like a lot of fuss, but it is really not... one SVN command to create the diff file, another to export a clean copy, and one php command to generate the package. If no pre or post flight is required, it only takes a very short time to get the package ready... And if pre or post flight is required, it only takes as long as it does to write those scripts.
You should be able to implement something like that with any framework I'd think.
Posted: Wed Apr 11, 2007 4:30 am
by Maugrim_The_Reaper
Subversion is a powerful tool for updating - it's how Wikipedia does it. They always run the latest branched version. DB changes of course a lot harder - but then you shouldn't be making many DB changes (none would be perfect) in a 0.0.x version. All it requires is isolating file changes only in the relevant branch, updating from that branch at intervals, and bang - automatic file updates which don't break the application. Typically bug fixes of course (the easiest updates).
Bigger updates (secondary releases) need a better plan - likely on the manual side via an update script (could be automated of course if it's really time consuming). PEAR could work here - it's a proven update system in PHP. Also subversion + PHP CLI via cron and a scripted process.
In terms of designing an updateable application - it's all in the OO. A near perfect OO design would isolate customisations from the base generic classes. Couple that with a fixed API and updating the generic classes should have little or no impact on the overall client installation. Updating is a design decision - you should stick on that first draft requirements list and keep the idea in mind when assessing code smells for refactoring.
Doing a very small sample app as a tracer might be helpful - it's grab the main problems you'd likely meet in the real application and afford some experience from any mistakes made.