I don't want dev to be exactly like stage and prod.
Yep, you read that right. I deploy to Debian servers but develop on Linux Mint or OS X. The key is that the environments are very similar but not identical. The payoff comes when you break yourself of the habit of relying on accidents of deployment instead of building a general-case solution that works in multiple environments.
You scan /proc to look at running processes? That's great, until you're on a machine without /proc. Better to spend an hour learning how your dev platform (Python, Java, whatever) abstracts that away for you. Trying to send an email by shelling out to /usr/bin/sendmail? Oops! That's broken in lots of places; better learn how your dev platform handles it!
The big win comes when you upgrade your stage and prod environments to a newer distro - or a different one altogether - and your stuff keeps working because you'd relentlessly whittled away all the OS-specific dependencies.
You describe a pay-off when upgrading stage and prod. But if dev, stage, and prod are identical, then you simply upgrade dev first, find the things that broke, do the same for stage, and then it's no big deal when you upgrade prod.
This strikes me as an example of an unnecessary/premature optimization. Unless you know that your product will need to deploy on an unknown variety of server environments, there's no advantage in taking the extra time to 100% abstract away the server environment.
And really, how trustworthy is that abstraction? You've basically outsourced responsibility for your server environment to your language community. What if they create a bug that is exposed on Debian, but not on OS X?
Yeah, for certain things your abstractions can either add a good bit of overhead or increase the amount of code you need to maintain. No real point unless your product really needs to run in a mixed environment in prod.
Yep, you read that right. I deploy to Debian servers but develop on Linux Mint or OS X. The key is that the environments are very similar but not identical. The payoff comes when you break yourself of the habit of relying on accidents of deployment instead of building a general-case solution that works in multiple environments.
You scan /proc to look at running processes? That's great, until you're on a machine without /proc. Better to spend an hour learning how your dev platform (Python, Java, whatever) abstracts that away for you. Trying to send an email by shelling out to /usr/bin/sendmail? Oops! That's broken in lots of places; better learn how your dev platform handles it!
The big win comes when you upgrade your stage and prod environments to a newer distro - or a different one altogether - and your stuff keeps working because you'd relentlessly whittled away all the OS-specific dependencies.