| > I quickly realised that trying to accurately replicate my production environments locally was not going to be a happening thing Your production environment should be easily reproducible via some sort of infrastructure as code system, or it could be built in containers/docker itself. In that case you absolutely can replicate your production environment locally incredibly closely. Usually the main differences are around scale and performance. I see this as good though as it is much easier to stumble upon performance issues on a local dev machine than it is on a blazing fast prod instance. > I would argue that's what staging is for. Just create a literal clone of your production docker stack either on your Mac or a spare Pi and run your tests there before pushing to production. Staging is for sharing and reviewing your work with other stakeholders before deploying to production. I prefer to not have asinine platform related bugs to show up when I am demoing my work around the company or with clients. Also in my experience staging is not a spare pi (which is also ARM!) or a local docker instance. > Further, if you have an m1 Mac your Docker environment will be running ARM versions of linux which almost certainly is not what you are running in production, so it starts becoming pretty clear that Docker on Mac is !== Docker in Production. It is still the same OS and is miles ahead of just simply being POSIX compliant. I would be interested in specific differences and issues you've seen in ARM linux vs. x86 linux, especially when it comes to the layers PHP operates within. > Re file system issues, you're absolutely right; this colossal thread Have you tried the VirtioFS experimental feature in docker desktop? With it enabled I can write hundreds of GB per day from docker to my macOS file system with no sweat. In any case, I was referring to differences between executing code on a macOS file system vs. a linux file system that matches production. macOS handles permissions and case sensitivity differently which can cause problems, especially for junior devs. Anyway, good luck with this endeavor. I am sure many will find it sufficient! |
> I quickly realised that trying to accurately replicate my production environments locally was not going to be a happening thing
Sorry I wasn't clear; my production environments are docker and as such yes, trivial to get running locally. My experience was that this was far less useful than expected. The moment I started turning on things like Xdebug and implementing mechanisms to deal with non-production .envs etc etc it became less and less useful for me. I'm guessing there are workarounds for all these kinds of issues (or you wouldn't be a proponent), but I do suspect that if you're developing locally in a 95+% clone of a production docker environment, you are one of very few who have managed it and enjoyed it enough to keep doing it. Which is to say you're a legend :D
> staging
Perhaps I used poor terminology; call it "Test". And the Pi was a poor example also, sorry! I don't run Pi's, and my personal dev circumstances are fairly atypical. However, I do feel it's solid advice to suggest that people:
a) run whatever development environment is most productive for you on a daily basis locally, so long as it closely replicates the production environment at the level your job requires. So as a front-end / back-end developer that means the same PHP/MySQL/Nginx versions etc.
b) run a clone of your production environment on a separate machine (local VM / local tiny PC / second VPS, whatever) for testing
> specific differences and issues you've seen in ARM linux vs. x86 linux
Absolutely none (as you probably guessed); I've never run an ARM server, nor had any issues between native binaries on x86 or M1 and their identical counterparts in production. As you suggested, the issues I typically face (and many like me, I expect) are at a different abstraction level from this; most boiled down to a) service configuration differences eg PHP extensions or b) file system issues (eg permissions & case sensitivity).
Re VirtioFS no, when I still used D4M I ran docker-sync with various strategies. It kinda worked. I then ran VS Code's Remote Containers. It kinda sorta worked. Both were annoying on an almost-daily basis.