[firesteelrain]

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.

[hnlmorg]

I 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.

I 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.

[firesteelrain]

When I say Production, I mean Production Software Development data like Coverity or Fortify databases. GitLab source code and pipelines.

The premise is that Software Development is akin to Production which it should be.

[hnlmorg]

That’s not the same thing as what people generally mean when they say “production data”.

And yes, your dev environments should mirror the production environments bar production data. That’s software development 101.

[firesteelrain]

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.

Within 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.

[hnlmorg]

> 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.