Best way to migrate content and various other changes from development to production

Question

I'm about to make a bunch of updates and changes to content types, views, themes and actually adding content on my development server. I was wondering if there was an easier way to migrate things from development to production beyond doing the following:

• putting the production server in maintenance mode.
• copying over everything (development -> production) from site root (excluding sites/default/settings.php)
• exporting the development database and importing it on the production server
• crossing fingers and hoping that nothing crashes for unforeseen reasons.

I've seen that there's already some posts on workflows that involve using the features module, but does it actually export content or settings changes to things like blocks and views? I was wondering if there was a module or a tutorial that I wasn't able to find on google that gave some good advice on this.

Answer 1

You can use configuration module to migrate changes from development server to live server.

The configuration management module enables the ability to keep track of specific configurations on a Drupal site, provides the ability to move these configurations between different environments (local, dev, qa, prod), and also move configurations between completely different sites (migrate configurations) without the use of modules with all configuration being owned by the site.

Answer 2

The main problem with deploying changes from a development site to a production site is the to me very annoying fact, that in Drupal version before D8, the database tables contain both configuration and content.

If you are the only one in charge of content, the deployment of updates and new features from development to production is straight forward:

1. Make sure the development site has the same content as the production site.
2. use backup & migrate to dump your current database content (development)
3. make sure all modules that you used are present in the module directory of the production site
4. import the development backup to the production site.

Of course, you should put the site into maintenance mode before applying the backup.

It becomes problematic, when the content of the production site diverges from the content of the development site. If you use the procedure above, you'll loose all content changes on the production site. This is where the features module becomes important (http://drupual.org/project/features), and lately the configurations module, which is a quasi subset of the features module just for configurations - still in alpha (http://drupal.org/project/configuration). With these, you can export the configuration updates from the development site, and then apply them to the production site.

Fortunately, Drupal 8 separates the configuration and content in the database (configuration only included in cache tables), so this problem will go away once Drupal 8 is ready for production.

For more details, see: Efficient and easy Drupal 7 Development to Production workflow

Answer 3

The most user friendly way to do the content migration you are talking about is by using the Backup and Migrate module.

You'll want to upload and enable the module on both development and production instances. The project page links to this tutorial series for a more detailed explanation. I also saw a helper module that backs up your files directory too.

Features does in fact allow you to quickly import a "feature" to a website that you may have developed on your development environment and want to move to production.

Ideally though, you'd want to use features to develop locally and then push to dev/staging server. The final push you'd want to just replicate the database from dev/staging to lessen the chance of configuration errors.

You could also use Drush if you want to do more advanced operations. You can write your own Drush commands and with aliases you can have this down to one command in a terminal if you'de want to. You can rsync files, sqlsync the databases, and use features commands to sync configuration options. Drupalize.me has a nice series on some of this stuff.

I highly recommend Drush, if you are getting more into Drupal, and also recommend checking out Drupal 8's CMI initiative for what lies ahead: https://groups.drupal.org/build-systems-change-management/cmi

P.S. I would have posted more links but don't have the reputation yet to do so. So, just Google the missing pieces.