WordPress DevOps – Environments

I’m unfamiliar with Docker beyond knowing what it is. But maybe my experience will inspire you to find a similar solution within Docker. I often develop on localhost. To avoid needing to change all the URLs in the DB when exporting to the target host’s server, I place the target domain in my local hosts file. Thus as far as WP is concerned, it is on that domain already and all the URLs are correct. The only drawback is I cannot access the domain’s real site except by IP address.

I would hope Docker has some sort of similar mechanism for domain alias that you can use. In cases where URLs still must be altered in the DB when moving sites, I rely on interconnect/it’s Search and Replace tool. You are right, there’s no telling where various modules will place URL’s. This tool is pretty good at finding them all. The one time it failed was for a theme that stored URLs that were base64 encoded! Why they did this I cannot even imagine.

I do have several WP installations on localhost. My public root .htaccess file redirects traffic to the proper subfolder based on the requested domain alias. It’s not been a problem at all. The subfolder appears to be the domain’s public root.

I hope this gives you some ideas on what to do with Docker.

Thanks for the feedback. Your solutions covers the URL part of the problem but i need to tackle the environments (dev, staging, prod). In this context i am looking for advices, experiences…

May I strongly recommend you stay away from any sort of flow (ie: Docker) that means there is a significant gap of time between a plugin being updated by a vendor and it being applied to your website. Especially in production, considering how important security patches can be.

Data is stored in all sorts of ways (as you noted above with the options table, there are many others to name too!)

If your goal is to deploy from your development environment to staging, or move from staging to production, then you are free to follow which ever process makes the most sense to you. That being said, my team tends to do the following when creating WordPress-based solutions:
– We create our dev, staging, and prod environments from a blank WordPress installation.
– We always keep plugins up to date using the autoupdater built-in to WordPress. The moment we notice a plugin can be updated, we go for it.
– We install custom plugins with FTP and any time one of our developers performs an update, they are responsible for updating staging first then updating production once they have tested their changes.
– For importing and exporting data, we tend to use built-in practices: https://codex.www.ads-software.com/Tools_Export_Screen
– For the above (importing/exporting data), as long as your developers are using the WordPress API properly you should be fine. If your developers are creating tables un-necessarily for things like custom post types, you might want to shake your finger at them for making your job much harder.
– If we need to modify a plugin that is not our own, we use WordPatch to make a patch and call it a day. Every time WordPress updates one or more plugins, the patch is re-applied and we don’t have to worry about losing our changes.

Hopefully this helps.