I am using a composer managed Drupal install and want to use git to move it between development and production environments. From what I understand, the only directory that is not supposed to be in the git repo is sites/default/files. Everything else incl. modules, themes, composer files etc. would be in the repo. Composer would only be run in local dev, but not in production.

What I don't understand is which content would be used in dev when the files folder does not contain the files from production? Is it just test content, for example created by devel generate? And what happens when a new dev joins the team? Will (s)he get a db dump from another dev system to set his/her environment up, because a db dump from production would include content linking to files that are not there due to the missing files directory!?

Hope you can help me to ensure I am thinking into the wrong direction.

  • 1
    Repo mainly consist of only custom modules, custom themes, and composer.json/~lock. Core, contrib and libraries are all managed by Composer. Yes, it's up to you to provide a way that every developer can sync a stage or live DB to their local site at any time. This can be done with Drush and a sites YAML. Then it's drush -y sql-sync @stage @self. Same applies for files drush -y rsync @stage:%files @self:%files, or use the Stage File Proxy module. Every developer always runs composer install and drush deploy in their local after pulling changes. – leymannx Jun 14 at 14:56
  • And you have to find a way to either upload the composer install build to Live with the CI or have it call composer install directly on Live after setting the site in maintenance mode, from a script maybe. – leymannx Jun 14 at 14:57
  • Thanks a lot! Would this still be the recommended way when deploying to a production site on a shared hosting? (afraid of hitting a memory limit when calling composer install and CI is not available in the project) I was therefore thinking about including even contrib modules in the repo. – Extect Jun 14 at 15:32
  • 2
    The CI approach has a bunch of benefits, but there's nothing inherently wrong with keeping vendor folders in the repo (in Drupal this includes core, contrib modules, contrib themes, etc). Shared hosting is a classic example where this pattern is very common, even nowadays, exactly for the memory issues you mentioned – Clive Jun 14 at 15:48
  • @Clive: Thank you for clarifying. Very helpful! – Extect Jun 14 at 16:11

Your Answer

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

Browse other questions tagged or ask your own question.