By pilnic on

Hello,

I have just started with Drupal. I am developing a community site around a web application and was considering three options, 1. Do it myself, 2. Use a php framework and 3. Use a php CMS and extend it. For various reasons I decided to go with no 3, at least for now, and picked Drupal from the available CMSs.

My concern now is making updates to my site when it up and running. I will be using a test server to test changes to layout, themes, modules etc. Some will be php code changes but things like menus, permissions etc are things that, from what I figure, Drupal inserts into the database.

Now, the code part, I assume I can just move over the drupal directory from the test server to the production server (save for the files dir), I don't suppose Drupal makes any changes to other files while the site is running, right?

But how do I deploy the database changes? Some tables obviously contain user data and should not be overwritten while others contain structural info (menus, settings) that must be copied over. Is there a definitive list of tables, which is which?

Finally, is this documented somewhere? Are there tools to do this?

Thank you

⋅ Categories: Drupal 5.x

Comments

vm’s picture

vm commented

I could be wrong here, but at this time the only way to do this, would seem to be, putting the production site in offline mode.

I'd probably clear sessions to guarantee noone is logged into the site.
I'd then export the production DB, make my changes, then import it.

set the site back in online mode

_____________________________________________________________________
My posts & comments are usually dripping with sarcasm.
If you ask nicely I'll give you a towel : )

shyamala’s picture

shyamala commented

I would also be interested in any documented methodology for the same. As of now we just not down the changes we make on the testing server and replicate it on the server. In case of a multisite configuration where you want to change the menu for many sites, how do we do it??!

Shyamala
Team Leader Netlink Technologies Ltd.

Shyamala
http://www.unimitysolutions.com

pilnic’s picture

pilnic commented

Ok, well, obviously I would not want to bring the site down for so long but the bigger problem would be whether I could really replicate precisely all the changes and fine tuning I was doing on the test server, the changes could be much more than the trivial addition of another menu item.

But that aside, I would appreciate it if someone with sound knowledge of the Drupal system could let us know if the procedure I outlined above can work, at least in theory, that is, coping the code over + copying some set of specific tables will work. If so, I can have a script apply the changes instantaneously, worst case a few seconds offline. Or is it more complicated than that?

Thanks

coreyp_1’s picture

coreyp_1 commented

I haven't had to upgrade a huge sight yet, so I haven't tested this method, but it's the one I'm planning on using.

First of all, it is completely acceptable for a site to be "partially" offline, where some features work, but not everything. Therefore:

  1. Disable anything that will result in new content being added to the database (node create/edit/delete permissions, new user sign-ups, etc.). This is "partially" offline part. All data is still accessible.
  2. Duplicate your database. We'll call the original "A" and the duplicate "B".
  3. Do your maintenance and changes to "B". You might clear your cache and sessions tables. You could also restore the disabled features at this time on "B".
  4. Update settings.php to use "B". In one swoop, your site should be completely functional again.

It should work, but I would be interested to know of anyone else's experiences.

- Corey

benthroop’s picture

benthroop commented

What you'd really want is a setup where you can develop and experiment freely on the test server, and then when it tests properly, push it to the production server. But yeah, since many development tasks involve creation of new data in the database, one of them needs to be locked to stay in sync.

Which has me wondering if having the test server running off of the production database makes any sense. Probably not, since there'd be new data (nodes) created with references that were invalid.

Quite an issue! If anyone has ideas, please share.

WorldFallz’s picture

WorldFallz commented

I believe what you describe is exactly the niche the http://drupal.org/project/autopilot module strives to fill. I've not used it so I have no clue on how successful it is as doing so.

===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz

donquixote’s picture

donquixote commented

subscribe