Serendipity Forums

Hi,

I'm setting up s9y on an existing site. We have a couple other applications installed already, and we've got version control system for it all. I would like to automate everything as much as possible, so the upgrade process fits into our current process, results are repeatable in staging, etc. It doesn't seem like s9y is tailored to working this way, but I bet it could work, but I want to make sure.

It seems that the installation and upgrade process A) alter some files and B) alter the database. We already do a regular backup of all the content in the site's directory structure, and of all databases. So here's what I have in mind to do, and I was wondering if I'm missing anything:

Installation:

On development box:
* Download, extract tarball.
* Run installation process via web interface, creating templates, .htaccess etc
* Turn off write permissions for web server to everything except for archive and uploads directories (I don't think we need template editing on the live site, we'll just do all that in dev, and check it into version control. But if we do later, I can turn on write perms for that directory as well.)
* Check in all files.
* save a mysql dump

On staging/live:
* execute mysql dump
* update to latest source control version


Upgrade:

On development box:
* Download, extract tarball, overwriting any files.
* Run upgrade process via web interface, updating templates, .htaccess etc
* Check in all files

On staging/live:
* update to latest version in source control
* execute any new files in /sql

Did I miss anything? Thanks in advance!

Hi!

Yes, that sounds like a good plan. The .sql files in the directory contain some intermediate PHP markup of s9y.

IMHO the easiest thing would be once you upgraded your live installation from the repository, edit the "live" serendipity_config_local.inc.php file to contain the old version number again. Then you go to the live blog (or you could even automate it with a wget) and confirm the changes, this will automatically execute the SQL upgrades.

You could also create a small PHP script that calls include/admin/upgrader.inc.php and modify it so that you can pass it the old and new version parameters, to force upgrades.

The benefit of this is that if in the future some other modifications or functions need to be executed (like plugins need to change their structure), this would all happen with our official upgrading process.

HTH,
Garvin

Great! Thanks a lot.

I will consider the automatic SQL bit, though we actually already have a process for running SQL during rollouts, so for our case it still might be easier for me to just copy the new sql statements into that.

Actually I just found one problem with my method. The configuration includes some absolute paths, and URLs. I'll have to do something about those.