0

I'm using (and loving) Pantheon to build out a new Drupal 7 project. All has gone well and now I'm live! And that's the problem... now that I'm live, I'm confused about the proper/best-practices workflow for updating configuration and code changes from dev/test, but preserving the real content in live?!

To put it another way, I have configuration changes (new views, settings, etc.) and code changes (new modules) in dev/test that I want to push into live... but I don't want to override the real content that's there in live.

So what now? Do I pull the code changes from dev/test into live and redo all of the configuration changes? If I use Pantheon's Workflow to "Clone the database and files from Testing into the Live environment"...

pantheon ...will I lose all of my live content? (That would be bad!)

Any advice on best-practices here would be appreciated!

closed as off-topic by Mołot, Bala, Letharion, Free Radical, Jimajamma Jan 23 '14 at 18:27

  • This question does not appear to be about Drupal within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • Yes, you will lose all of the content in live (if the DB doesn't match your "test" environment) because you are overwriting your "live" database. – inertialmedia Jan 23 '14 at 2:43
  • @inertialmedia That's what I was afraid of. Thanks for the confirmation! – Sam Jan 23 '14 at 3:51
  • 2
    This question appears to be off-topic because it is about Pantheon, and not Drupal. – Letharion Jan 23 '14 at 9:38
  • Okay. I'll buy that. I could adjust it to be more generic as I think these concepts extend beyond just Pantheon sites. But... should I? – Sam Jan 25 '14 at 3:41
1

Pushing a database from test to live is considered bad practice, which is why this is not a built in function on Pantheon. Generally speaking, once a site is up:
1. code should go from dev -> test -> live
2. database should go from live -> test -> dev
3. Configuration changes should be placed into code where possible.

Features and Strongarm work well to export database changes to code.

  1. Change Database settings on dev
  2. Add those changes to a feature.
  3. Commit those changes and other code changes to git.
  4. Push feature to test and enable.
  5. Test to make sure feature pushed cleanly and appropriately

    • if it fails start over from dev.
  6. Redeploy to live and enable feature again.

In the future, all changes to those settings should go through the same feature. I.e. If a feature contains a view, all future changes to that view should be redone on that same feature and pushed that way.

Features is picky. If a dependency is missed, it can break on deployment. If more than one feature contains the same configuration, the features will go into conflict, which can break functionality. As long as all configurations that are necessary are included, all unnecessary configurations are excluded, and you make sure to test before deploying to prod, you should be fine.

If features is too complicated of cumbersome, Deploy module is a good way to redo work on live automagically.

Finally some database settings, such as views, can be exported. Export the view on test, then copy that code, and import it though the GUI on live.

  • That makes sense. Thanks! I think I'll give the Features module a shot. But before I do, any thoughts on the Configuration Management module ( drupal.org/project/configuration ), which claims to "provide the same functionality as a subset of the Features module"? – Sam Jan 23 '14 at 3:50
  • I have never used it, but the description is correct: Features was not designed to provide configuration management, it picked role up as it developed. As such, working with it can be trying sometimes. If Configuration Management module does what it claims to do, it sounds like a much better solution than Features. – user204992 Jan 23 '14 at 4:24
  • I just tried out the Configuration Management module to move configurations from Dev to Test. Seems to work great! Although there is a bit of a learning curve. One thing that is a bit disconcerting is the warning that you receive right before you import: "Importing configurations will write your configurations directly to the activestore. DO NOT USE THIS ON A PRODUCTION SITE!" Isn't that the whole point though? To use this on a production site so you don't have to redo your configurations? – Sam Jan 25 '14 at 3:19
  • Apparently, Configuration Management is only in Alpha: drupal.stackexchange.com/questions/101120/… – Sam Jan 26 '14 at 3:16

Not the answer you're looking for? Browse other questions tagged or ask your own question.