Drupal Answers is a question and answer site for Drupal developers and administrators. It only takes a minute to sign up.
Sign up to join this community
The migration is from the local environment to the production environment. The production environment has run some time and created a lot of articles.
In order to add new things to my site, I added a custom theme and installed CCK, Views and other modules in my local test environment. Now that the local test environment is finished, how do I migrate it to the production environment, without destroying the content of its database?
This is a non-trivial problem that almost everyone has a different answer for: there isn't a canonical Drupal way to handle staging to production pushes. Dries Buytaert, the guy who runs the Drupal show, made it one of the key initiatives of Drupal 8. Of course, Drupal 7 was just released, so it'll be a while before that bears any fruit.
The problem can be broken out into two separate issues:
The former can be mostly handled by the Features module, which will take your site configuration and turn it into a module you can add to your Drupal installation: this way, you can add it to your version control system and not having to worry about it being blown away when you migrate your content.
The latter is really tricky, because on an active site, it's likely the content will change on production even after you've made the initial sync to your development environment. This prevents wholesale replacement of content during staging like you can do with configuration.
Additionally, Drupal doesn't use universally unique identifiers (UUIDs) for content: every time a node or a user is added, the ID increases by one. So what might be node 45 on your development site might be node 90 on your production site.
Unfortunately, I don't have a great solution for this: staging content is a real weakness of Drupal. What I personally do is add content on the production site only. If a client wants to see how the content looks prior to it going live, I'll set up a clone of the production site that's only accessible to the client. Then, once approved, the same changes are then made directly to production.
There's another alternative that gets tossed around: the Deploy module. It's supposed to leverage Services to make staging content relatively painless. But I can't vouch for its effectiveness and it doesn't have a Drupal 7 version.
In our process.
We are using Hudson to rebuild our dev/staging branches to sync live and dev branches.
Since we are using Git, every task we are doing has its own branch, then when passed to QA we merge it to master as our staging server for regression testing.
When master is ready we do a test release to our Release Server which is a replica of live (configuration, hardware, etc).
We use Feature module to deploy configurations. Some stuffs are not yet supported by feature so we use hook_update_N then run updatedb.php or drush -vd updb
drush fra --yes) to revert all overriden feature.Since we are using Boost(moving to Varnish) and Memcache, we need to clear the cache(drush cc all).
We are using rsync to sync our images/video etc...
To Migrate from a XAMPP server to another server, I followed the instructions on this site.
Make sure that you keep the same structure on your production server as you did on your development server. I also had to edit some files in Drupal admin dashboard located at: admin/config/media/file-system
Ensure that your Public file system path and Temporary directory have the correct locations set.
