0

I have a setup that consists of a Drupal 8 instance on my localhost, a staging instance on a develop server and a productive version on a production server. Initially, I was co-designing the theme, the configuration and so on on my machine. But now, the site is live.

For configuration changes, I can update my local instance and export the configuration. Pushing this to my develop branch in my git repository automatically triggers a deployment on the develop server. Creating a new release triggers a deployment on the production server.

Now this situation: Content editors create new nodes on the instance on the production server. On some piece of the new content, they discover an issue and want a fix for that and maybe even want to review this fix on the develop instance.

I already have such a neat deployment for the configuration, so I really want to avoid copying databases around. For images, there's a module, that can replace local static files with links to the productive version. What would be the equivalent solution for the content in the database?

What might be a useful flow for the case that there's no better automation:

  • I do a composer update on my local machine
  • The content from develop gets pulled to my local instance
  • I commit my changes and pull them to the develop instance
  • The develop instance pulls content from the productive instance
  • The develop instance reads my new configuration

It would be even better if there would be some API magic that enables my instances on localhost and develop to read the content directly (and cache it).

So, is there some API magic around? Or do I have to write scripts and everything to pull databases from server to server?

Additional requirement: I did most of the work so far and have all the administrative rights, but in the future, this should work for additional developers who should not need to login onto a server.

  • 3
    Code goes up, data goes down. You don't want a setup where other environments "touch" production in the way Stage File Proxy does. Copying the database down is fine, and Drush has a sql:sync command to make this easy. The UI in Acquia and Pantheon and probably others make this a simple drag and drop. – Kevin Jun 23 at 14:01
0

Content is particularly difficult to Migrate. It's not as clean as Configuration. Generally, what you are talking about is not done - as Kevin points out, content is created on prod, and databases are pulled from prod to any other environment that needs that content. That said you could set up a Migration strategy with the Migrate API that could be used to migrate content around between environments. You're mostly on your own with this though - I haven't seen any tutorials for your specific issue.

| improve this answer | |
  • Ok, thank you. I guess, that is the answer for now. I have some ideas how to do this customly. I just didn't want to start coding this on my own if there's a chance, that I'm missing something. Thank you :) – Günther Gut Aug 3 at 19:53
  • I would definitely use the Migration API. It still needs maturing overall, but is better than starting with something custom. – Jaypan Aug 5 at 7:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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