I'm working to achieve a test server + production server setup with Drupal. With code, it's easy. Just make the changes in test, then copy to production when they're ready (via a Subversion repository for extra credit).
However, database changes are problematic, and just about any development that involves clicking the Administration menu consists of database changes. The best practice guidelines on drupal.org and other sources suggest either (1) keeping notes on all activity in order to repeat the exact same sequence again on prod, or (2) copying the whole prod database to test, making all the changes, then copying it back. The former technique is time-consuming and error-prone. The latter technique loses any comments, posts, user registrations, and other changes made in the interim. (Unless the site is brought down during the changes--but a major purpose of trying changes out on the test server in the first place is to keep them from bringing down the prod server.)
Has anyone thought about making a script that copies only the configuration-related tables of the site to production, while leaving the content alone? Doing so would made configuration changes as easy to replicate as code. Certain actions would need to be performed twice, such as adding new CCK fields, because the database schema of the content changes. But many changes including variables and menu items should be transferred.
I've actually written a first cut at this, after categorizing a lot of tables. But so I know better what I'm getting into, does anyone else have experience with this kind of setup? Do any problems come to mind?
Comments
See AutoPilot
See http://workhabit.org/projects/autopilot -- code release forthcoming...
--
The future is Bryght.
subscribing http://drupal.org
subscribing
http://drupal.org/node/140290
Subscribing
Subscribing
Subscribing
-------------------
http://www.PrivacyDigest.com/ News from the Privacy Front
http://www.SunflowerChildren.org/ Helping children around the world
subscribe
you say there is some code for this?
http://www.xweb.com.au
subscribing
=====
HigherVisibility
Project committed
See http://drupal.org/project/autopilot and blog announcement here: http://www.workhabit.org/autopilot-alpha-released
--
The future is Bryght.
Boris, do you have 'inside
Boris, do you have 'inside information' about this project, then?
Because the last information update by Earnest Berry was June 2007, over a year ago. And there has only ever been one development release (Aug 2007) http://drupal.org/node/169057/release. So it appears like a completely dead project to anyone on the 'outside'.
If drupal developers found a way to make development updates to a live site without closing the site down for the weekend, or having to manually reproduce and apply dozens of changes to a live site, I think we'd all be very happy, but I think it is probably a bit of a pipe dream?
Deploy
It doesn't like like Earnest / WorkHabit have had the time to finish this off. The Deploy module is a piece of the puzzle, but doesn't solve everything.
--
The future is Bryght at Raincity Studios
Subscribing - Autopilot Looks DOA
Seeing that there have been no Autopilot updates and it is still for Drupal version 5.2 and not 6 my guess is that Autopilot is dead.
Has anyone seen anything for 6.0? I know 7 is right around the corner.
My main concern is separating the configuration info in the database from the content in some automated fasion so that I can create a testing site with a duplicate database from the original production site.
Then when I am ready lock the production site. Pull in all its latest content. Test the latest content on the testing server, and then push the testing site and the updated testing site database to the production website.
sub
===
How do you do this manually?
Automatically would be great but I'm having enough trouble doing this manually - specifically any new nodes I need to migrate are overwriting anything my users have written in the forum.
Does anyone do this without losing info and if so how?
> Does anyone do this
> Does anyone do this without losing info and if so how?
As far as I'm aware, there is no smart way to continue radically developing a site once it is live. After you've tested the changes on a dev site, you simply have to close your site so no new information is added by users, manually apply your changes, and re-open the site.
It's a bit of a holy grail to be able to make substantial developments without shutting your site down. It would take really smart merge/sync software to do it without error.
Thank you for your reply
I have a bit of a special situation since the ONLY things users can do is write in the forum. A non-admin can write forum topics and comment on them - nothing else.
So it's probably a little simpler that most other cases would be...
I was thinking maybe to manually set sequences.node_nid to something like 10000 or more, which is likely to sort out most of my troubles... I'd just need to merge the testing in to the production somehow.
The idea of having to manually reapply changes makes me cringe... it's bad enough when import/export is a possibility (workflow-ng, CCK).
Long discussion by heyrocker about deploy
http://heyrocker.com/drupal/content/deployment-and-change-management-wha...
He has a presentation somewhere talking about shifted sequence tables and various other potential options and their related pitfalls.
--
The future is Bryght at Raincity Studios
Thank you
I didn't come across that before. Very helpful!
Site Development With Test Site
I use a test site regularly, derived from a backup of the live site. In essence, I "backup" the live test site to another domain on my server.
A script makes a dump of the live site's database, then does a simple "sed" find/replace for all occurances of the "live" site's domain name and replaces them with the test site's domain name in the dump file. It also does a find/replace to change the "live site's database name with the test site's database name, so there are 2 complete functional independent identical databases in the end.
(to keep the correct key lengths intact, the domain names MUST be the same length. example: livesite.com and liveback.com = both 12 chars. Some tables are not stored as plain text, so this is necessary.)
Then, the script copies the entire live site's files from the live domain to the test site's domain, and does the same find/replace on the "settings.php" file of the test site.
Finally, the script uses the "live" sites dump file (with the altered domain names and database name) and uploads it to the MySQL server as the test site's database.
For a site with 9000+ nodes, this takes about 40 minutes.
You can then log in to the test site to experiment, and it will be exactly like experimenting on the actual live site. This is a safe way to always have an updated test site to work from... indeed several people can be working on different projects on different test sites this way, with a little collaboration.
Notes: When updating to the live site, you keep a log of your test changes (Done while logged in to the site) and duplicate them on the live site. Good news is whatever changes you make to module files, CSS files, or any server files OTHER than the database, can just be copies straight over from the test site to the live site to install your changes. (This does not include the database unless you want to reverse the find/replace processes and lose any settings done to the live site while the test site was worked on)
Transferring Views settings, or other settings done logged into the test site itself must be repeated on the live site if you don't want some users' data lost from the live site during the process, but if you keep a log, this doesn't take long at all compared to the actual test production time.
Using this method, I can produce radical changes on the test site, then update the live site in a tiny fraction of the downtime it would take if working right off the live site — with no data loss on the live site at all.
Again -- setting up a fresh copy of the live site to work on takes about 40 min and is fully automated. Completing the changes of days or even weeks of production on the test site to the live site has never taken more than an hour, with no data loss and complete confidence in the outcome. :-)
(if you have lots of users with email notifications, then turning on Reroute Email on the test site has been an awesome key to this method)
subscribe
subscribe