Some background…
I help managed two wordpress blogs… both that are pretty media heavy. Our “light” blog is only 4GB, our larger blog is 11GB.
How do you guys deploy your changes to your production servers?
For me, all of the wordpress plugins designed for this seem to half-work. Duplicator used to work well but doesn’t play nice with Cloudflare any more as far as we are experiencing. All-in-one-WP migration is great but a little cumbersome with a large site like ours unless you purchase a subscription. They all have their quirks. These plugins always take hours (I don’t have a Gb connection and with a slow upload it takes forever to “restore” the backup file they produce).
Is it possible to have our entire wordpress blog reside in a git repository? How could we “push” the database then as well?
What are you all out there doing!? I need some ideas to make my life a little easier. 🙂
[ad_2]
Commenting to follow…
Offload your media uploads folder to Azure blob storage will reduce your installation size down to that of a new WordPress install. It will make go live much easier
Initially I started out with those ideas but eventually just created a couple of my own scripts that would package and deploy everything. Once you break everything down into smaller steps the overall isn’t too bad.
Staging: Zip /wp-content/, export the database
Production: do the opposite. Use Better Search Replace to change the domain.
What changes are you making in staging? Typically if I’m doing stuff in a staging env I don’t mirror the whole /uploads folder for sites with a large uploads folder.
We use Git to manage code deployment, with branches set for each environment (local, staging and production). You could pack an .sql file in there too for your db but that’s not what Git is intended for and I wouldn’t recommend that. Git at its core is for tracking changes you make to code and to prevent devs from overwriting each other’s changes.
Data/content we handle separately but all content is really managed on production; staging is just for testing things and all new content is written directly in production. Twice or so a year we manually update the staging db to match production but again, it’s just so we can test with more recent content.
We deploy through a service called Beanstalk, but you could easily use Github or Bitbucket in its place, it’s basically the same thing.