1

Use case:

2 git branches:

staging (wp4.7x -- or whatever) production (wp4.7x -- or whatever)

Then I do a wordpress update on staging. Then merge staging files on production.

At this point, I will have all the most updated files on production, but the database wasn't touched. Dangerous? Or maybe wordpress will detect old db and ask to update?

Improve this question

1 Answer 1

Reset to default
2

For DB upgrades wordpress compares the db version number it hs in the code to the one in the DB. It makes no difference how the new code got there as long as it is the correct one. Which begs to caution that if you go that way you should put wordpress into maintenance mode before pulling from git (I will admit of not doing that myself, but it is still a risk better avoided).

Improve this answer
3
  • Is there any way to automate the database upgrade during the deploy process? I am thinking about a zero-downtime deployment to avoid any downtime (as would occur when putting wordpress into maintenance mode).
    – Richard Kiefer
    Commented Oct 23, 2019 at 7:15
  • Also, do you have any sources regarding the database version tracking and its updates? I could not find any, apart from codex.wordpress.org/WordPress_Versions but it does not mention any mechanism details.
    – Richard Kiefer
    Commented Oct 23, 2019 at 7:29
  • This sounds like a different question, but in general for "zero" down time you should use two DB probably as part of load balancing of some kind, and if you care about downtime you most likely already have two DB servers and load balancing. As for sources, it is in the wordpress code (which actually follows a very common practice for doing upgrades)
    – Mark Kaplun
    Commented Oct 23, 2019 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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