At IDEIA we are currently working on a new (simple) staging solution.
I have evaluated many systems like : Features, Drush, StrongArm, Context, Patterns, DBScript, Migraine, Deploy, Node_Import, Feeds, Staging, etc...
The common problem encountered with theses modules are :
* they are compatible with few modules
* needs many manual operations and double checking
* handle only content, or config but not both of them
The only "global" solution is DBscript, but it's not a real module, not easy to configure (you must describe all foreign keys of your DB in a config file).
So we came to a new method, based on MySQL auto_increment_offset. These ID pattern allow to know from which DB came any content of any table in the DB.
For example, if we choose that ID terminated by 1 are "prod server", ID terminated by 2 are "test server", and ID terminated y 3 are "dev server".
So merging dev / test / prod is rather simple with some basic SQL UPDATE and DELETE for each table.
Currently we have a proof of concept module. To be really useful it would need at least some custom profiles and drush support.
I would like to get advices on this method. I wonder why no one ever implement it, since it's rather the most simple solution ?
Maybe I'm missing something important.
Easy to configure (new modules needs only to decide if new tables are "config/content/ignore"), easy to use, handle full merging.
Drawbacks are : no versionning in php code. Only work for DB on the same server.
These are easily adressed with some scripting.
It also work with already existing DB (even if the ID pattern is not respected)
Comments
Staging Discussion
I started a discussion on staging and Drupal 8 under the Improvements to Core group:
http://groups.drupal.org/node/66958
-Myke
Report
I have finally used this solution in a real production environment with a real site. Now I can see the problems and limitations that this solution cannot override, and also, how much it is useful. A module have been created, a new one, more useful and intuitive is in development.
The most important (for me) is that it can work, and, once well configured, it's really a "one click" staging solution.
The process enlighted different types of table in the DB. Those with "auto-increment" are the most simple to handle. I mean :
* node, node_revision, term_data and so on.
Then we have all the non "auto-increment" tables. Some of them are hidden "auto-increment" tables, like :
* content_field_* content_type_*
there are pointing toward "node_revision".vid. It can be handled like the previous one.
Then we have the "string" primary keys, like variable, or menu_router. menu_router can be reconstructed, and variable can be "locked" in "test/prod" environments.
Then comes the real tricky ones like term_data. They can also be merged, but, we have some "political" choices to make to determine what is the priority : is it the term or the node that is the most important.
The conclusion is that there is, and there will not be a real generic solution. We must ask collaboration from modules to know how to do the staging. But even then, there are some "political" choices that no modules can handle. So the final staging solution for Drupal 8 will not be easy to implement, but we will a way, I'm pretty sure :-)