-1

I have a production environment for a Drupal 7 site.

This environment is replicated to a staging environment, which we use for testing updates to modules and drupal core (same major version).

We would like to sync this environment with the production one everytime we want to test an update, and then replicate the changes.

The way I envision the process is the following:

  1. rsync everything from production to staging, getting the updated content from production and crushing any staging changes, deleting any files from staging that do not exist in production

  2. replicate database from production to staging, so we can test pages and functionalities on production content replica

  3. perform updates on the staging environment

  4. rsync from staging to production, not deleting in production content that might not exist in staging

Question #1: Do updates make changes to the database? Or are these file only changes? Will rsync be enough to get the production in sync with staging after the updates?

Question #2: Is there a better, more robust way to achieve this?

Question #3: Should I set the site into maintenance mode while doing #4? Can this be done by setting maintenance mode programatically in a config file, rsync that file and everything else, then reset the maintenance mode and rsync that file? (I am looking to build a script to automate this)

closed as primarily opinion-based by mradcliffe, Pierre.Vriens, leymannx, kiamlaluno Jun 3 at 5:22

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Generally, yes, this will work like you envision in #1 and #3, but some files shouldn't be persisted from an environment. I think that the question is too broad and opinionated for an answer because it depends heavily on how the infrastructure is setup. Things you may be overlooking: database back port and sanitization (possible with drush), settings files, running database updates or other drush scripts as part of your deployment process. – mradcliffe May 21 at 20:03
  • thanks @mradcliffe this kind of defeats the purpose of the script. There's no point in using rsync to do this if updates require database changes, unless I would do some sort of diff in the database. I can keep step 1 of the process, but there's no point in automating the rest. – BlunT May 21 at 21:04
  • I disagree. rsync is just a file transport tool and perfectly fine to use to deploy build artifacts from one environment to the other, and can be used together with drush to perform "database updates" (or any type of drush script) automatically. I would recommend thinking of non-production databases as non-persistent, temporal state. Those exist as a way to test the build artifact, whether in a linear fashion or a review-based one. I've worked with schema compare before and it just ends up with messy permanent environments in my opinion. – mradcliffe May 22 at 9:42
  • There's also content staging and deploying content, which gets complicated. Again, depending on how infrastructure, content work flow makes sense, but if the core (or contrib.) content work flow doesn't seem to please content reviewers working in production and they insist on being able to review things in a non-production environment, then there are several other models for deployment, – mradcliffe May 22 at 9:51
  • @mradcliffe I am not sure exactly with what you disagree, but my concern is: What point is there to using rsync in step 3 if I still need to run the updates directly on the production environment, so database upgrades are performed. Or am I missing something? – BlunT May 22 at 13:37
0

Question #1: Do updates make changes to the database? Or are these file only changes? Will rsync be enough to get the production in sync with staging after the updates?

Updates will most likely do changes to the database. That's where most of the fun comes in when doing updates :D

Question #2: Is there a better, more robust way to achieve this?

Syncing production to the staging system every now and then is a good idea, I'm not sure if you need it everytime you want to test something. I'm assuming your deployments go through that staging system as well, so your content there will already be something you can test with. As far as I know there is no way to be 100% sure you're not going to kill your production environment. That's why you back up the database and the code and everything, before doing any change to production.

Question #3: Should I set the site into maintenance mode while doing #4? Can this be done by setting maintenance mode programatically in a config file, rsync that file and everything else, then reset the maintenance mode and rsync that file? (I am looking to build a script to automate this)

You can set the maintenance mode using drush. https://drupal.stackexchange.com/a/32/47426 To disable maintenance mode, run the same command with 0/FALSE instead of 1/TRUE. And don't forget about the cache clear.

  • thanks, this kind of defeats the purpose of the script. There's no point in using rsync to do this if updates require database changes, unless I would do some sort of diff in the database. I can keep step 1 of the process, but there's no point in automating the rest. – BlunT May 21 at 21:04

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