April 12, 2009 - 1:07am
How does this sound?
Let's take a worst case scenario (worst because it's even easier if you're running on a VPS or private server) and assume that you're running on a typical shared hosting account that allows you multiple add-on domains and forces the account's "primary" domain to be resident somewhere like /public_html.
Let's use Rob's favorite and assume that your site is mysupersweetawsomechurch.org. When we register the hosting account we use a domain name that we'll never use for public access. It could be something like mysupersweetawsomechurch.net or mssac.org. It's incidental to this scenario but our primary name should be registered with a different vendor.
Let's take our current, production version of the site and install it at /public_html/prod and use a database named d5.
Let's create a new directory for our new version at /public_html/new, and another new directory for an "old" version at /public_html/old. Let's create two subdomains: new.mysupersweetawsomechurch.org pointing to /pubic_html/new, and old.mysupersweetawsomechurch.org pointinng to /public_html/old (there won't be anything there, but that's OK).
Install the Backup and Migrate module in your Drupal 5 (production) site.
Even though you have many people updating your production site you should be able to establish times when you can take the site down for an hour or two to maintenance.
Put your production site in Maintenance Mode; backup /public_html/prod and all it's files and use Backup and Migrate to backup its database. Put the site back online.
Restore the files you backed up from /public_html/prod to /public_html/new. Clear your d6 database (if necessary) and load it from the backup you took of the production database. Update settings.php to use the d6 database.
Now your new.mysupersweetawsomechurch.org site is running a copy of your Drupal 5 configuration. Test it to make sure it works.
Upgrade new.mysupersweetawsomechurch.org to Drupal 6, core and contributed modules. Take your time; test whatever you want.
Let's now assume that your new site is working to your satisfaction. If you've added new views or content templates, etc. you probably want to export them.
Go back to the production site and put it in offline mode. Backup the database and your site's files directory(ies). You could put it back online if you tell users not to make updates or warn them that their updates will be lost.
Clear out the d6 database and load it again from the backup you just made. Load the old site's files in the new site's files directory.
Run update.php on the new site. Import any views or contemplates you saved from your D6 testing, or recreate them. Enable any modules you added to d6.
Test new.mysupersweetawsomechurch.org. Everything should work. Backup your files and database for the d6 site.
Rename /public_html/prod to public_html/old. Rename /public_html/new to /public_html/prod. Since you tested everything just before this step everything should be working and mysupersweetawsomechurch.org is now running your Drupla 6.
Create a new /public_html/new directory; restore your backup from your new directory before it was renamed. Update settings.php to point to a new database, say d6a. Load the d6 database into d6a. This is now your new testing/staging site.
Parts of this process are a little risky, but the risk is always taken in the new.mysupersweetawsomechurch.org site. If it doesn't work, we always have our production site still available. If we encounter a problem soon after switching, we still have the "old production site" loaded, with its own database, in /public_html/old so we could rename directories to get it back.
Is this procedure guaranteed to work? No, but I think it will. Have I used it? Not yet, but I expect to in the next month, or three.
Others may have different, and probably better ideas. Let's hope that they point out the holes in this plan.
Curt
April 13, 2009 - 8:27am
db updates with update system
One of the things that's quick and easy to do so you don't have to manually make those changes is to use drupals update system. The update system, if you don't know, let's drupal update the database config. In drupal 6 it's designed to handle things in a batched manner to avoid php timeouts.
If you are repeating the exact same tasks each time, write them into an update and when you update your d5 database to d6 they will be automated.
I'd suggest making it a custom module. The api hook you'll need it hook_update_N. It will only run once. There are details at that page.
This is a common way to automate those tasks.
I am in the process of upgrading our churches website from D5 to D6. We are also in the process of making some changes to the content, what/how it is displayed, etc.
For sometime now I have had a test site setup at newsite.rcovenant.org that mirrors the production site from an installed modules/database perspective. I sync the content from the main site back to the test site at times just to make sure new problems are not introduced, etc.
However, this means that whenever I want to make significant change I have reset the test site to the state of the current production site. Then methodically apply the changes (taking notes on the order, settings, etc). Test to ensure no bad results, then follow these steps again on the production site, assuming we are ready to move forward.
In my day job (not drupal related) we have automatic build processes that will deploy from testing, to staging, to production. I have no issue with setting something up like this, but I dont see a way to effectively set this up. Content is being added to the production site on a regular basis by a number of individuals, so I cant just deploy the staging database to production, and there doesn't appear to be a very automated way to apply changes from test to production.
Is there a better way to do this? What do people suggest for automating changes to deployment across servers?
Everette Mills
***************
www.elmills.com
Volunteer IT Admin for
Riverside Covenant Church, West Lafayette, IN
www.rcovenant.org