When we do updates, I mandate that our teams do blue/green deployments meaning they setup the exact VM side by side with the actual production data and test with the new version of software (eg GitLab) before doing the DNS flip. This is on prem. It’s an ephemeral sandbox.
replyI don’t think I’ve worked in an industry where it’s safe to use production data in a non-prod environment in probably 20 years.
replyI think for dev, it’s fine not to have blue/green. You want dev deployments to be fast. UAT / pre-production/ or whatever your final env before prod — and particularly if stakeholders are intended to test on that env — is a different matter.
When I say Production, I mean Production Software Development data like Coverity or Fortify databases. GitLab source code and pipelines.
replyThe premise is that Software Development is akin to Production which it should be.
That’s not the same thing as what people generally mean when they say “production data”.
replyAnd yes, your dev environments should mirror the production environments bar production data. That’s software development 101.
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.
replyWithin 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.
This isn’t only for your (deployed) Production environment.
It’s also not software development 101. This has roots in ITIL.