> You are still mixing production and dev contexts. What is called software development environment is production for your software factory. It’s not development in terms of a sandbox for your deployment, Production environment.
You’re the one drifting all over the place with the terminology.
I get what you’re trying to say. But you’re saying it badly.
You have your dev, test, UAT, production, etc environments. They’re the “software development” envs as you named them.
You then have your DevOps envs. You call them sandbox, but Personally I hate that term because the DevOps envs should be the same as the “software development” envs just not accessible to the software developers. A “pre-dev” env if you will. So it should be the same IaC and the same build pipelines.
Whereas a “sandbox” generally suggests that it’s “ClickOps” / manually provisioned envs with no rigour. A place to
play and experiment before you’re ready to commit your infra to code. Which is not how the DevOps envs should exist. The DevOps pre-dev envs should still be a carbon copy of the “software developer” environments.
> ithin your software development environment (which should be treated as prod to maintain velocity), you have blue/green when doing deployments, established SLAs, backups and DR
No it shouldn’t. HA, DR, etc costs money. Blue/green is slow and you shouldn’t let DevOps be a blocker for development feedback loops. So you save that stuff for your pre-production envs, and keep your dev and test envs nimble and quick to deploy. The DR for your lowest environments should just be “destroy and recreate” because you’ll have pipelines to deploy that infra.
In short. You can still have the same approximate infra but you shouldn’t emulate production best practices precisely across all development environments.
If you find you cannot have a “production-like” dev but without the HA, DR, etc, then you have designed your pipelines wrong from the outset. Eg You’ve got “pets instead of cattle” (ie the lack of ephemeral infra), manually provisioned services, and other faux pas.
> This isn’t only for your (deployed) Production environment
It isn’t. But it’s also not for all environments indiscriminately either.
> It’s also not software development 101. This has roots in ITIL.
Of course it’s software development 101. If your developers don’t understand the basics of different software development environments then they’re either shit at their job or fresh out of uni. I don’t mean to be harsh here but I don’t know how else to emphasise that what you’re describing here is the absolute basics. 30 years ago, when I was starting out, I learned this before I learned about version control. That’s how basic a topic this is.