Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By ardee-1 on
You've got a Drupal-based site up and running. People are visiting it. You don't want to bring it "down" but you need to make some large or risky additions or modifications to the site. And this situation will recur again and again as the site gains features. So you decide to "branch" the site (make a copy of the whole thing, including the database), work on THAT, then, when it's just right, merge it back into the main (live) site.
But this branching/merging process can be tricky -- especially the merge, since it involves Drupal databases. Plus, you want to do this again and again -- perhaps once a month. It seems like a lot of time, effort, and risk.
How do you go about making this process as painless, risk-free, and automated as possible?
Must you manually determine which database tables will be changed in the copy, which will continue to grow in the original (as content or terms or whatever are added), and which will change in BOTH? And how DO you merge tables that have changed in both copies?
This must be a common problem that smart people have solved many times over the years, for Drupal sites and other database-driven sites. Advice appreciated on how YOU set up such a recurring branch/merge process!
Comments
subscribing
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
NancyDru
---
I'm not sure what you seek can be done without a lot of manual work in the databases.
Putting a site in maintenance mode is preferable because it stops users from adding content, while you are upgrading or updating a site thus the database isn't changing as you are in process of change.
I've experienced many sites who use maintenance mode, my online banking service does so for example. usually in the wee hours of the morning on a sunday when necessary.
Typically I don't make changes to a production site, I work with a test site, so that my live site stays live, once i make adjustment and learn that all is working 100% i put my production environent in maintenance mode, using the text to inform visitors of whats happening, why and when to return. I then kill all sessions, clear the cache tables and go to work on the production site, implementing the changes exactly as I did on the test server.
I believe some people use CVS for this type of situation too, where one would be hacking core files, or testing out custom code. File based changes really aren't as big an issue as database changes as the files are just pushed to the production site. I read a thread not too long ago about how some dev's use CVS as a go between more less, but can't seem to find it now, it was on groups.drupal.org. It was dealing more with developing a test site than pushing that site to the production environment. That being said, it may not even fit this use case.