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?


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).

  • 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 Oct 23 '19 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 Oct 23 '19 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 Oct 23 '19 at 16:28

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.