https://devops.com/dear-staging-wer...

What the F#*@&$# %#@$!?!?!

This person has decided to skip using staging, because it doesn't correctly reflect prod!

If that's your problem, than why don't you try to fix it? Create a DB with fake data, make one based on anonymised customer data, or even do it on non-anonymised data (with permission of course), but fix the staging env so that it reflects prod!

This is a devops site (it's literally the name!), and instead of teaching you how to make staging exactly like prod, they tell you to do what caused the creation of the staging->prod system IN THE FIRST PLACE!!!

There's all these stuff like Vagrant that are literally designed to help you as a dev mimic prod, and you just throw it all out!?

"With feature flags, I can safely test in production without fear of breaking something or negatively affecting the customer experience."

Famous last words.

"Iit's fine, I think I packed my parachute."

The fun thing is.

It's essentially what made C / C++ a nightmare.

I remember the pain of C programmers that had to deal with an "include guard whore"...

I supported at that time a lot of packaging in FOSS. And when you read certain bug entries, it became pretty much evident why packaging can be one hell of a nutjob.

It breaks.... But only if I apply the combination of libraryA with libraryC in conjunction with configuration flag D to enable featureA.

Usually fixing such breakage took quite a time. Since you had to try a few combinations before you were sure that the changes in the Include Guard didn't break stuff somewhere else.

Feature flags are essentially that if I understand it correctly (too warm, I only glanced over the articles).

Code get's cluttered, Code get's conditional and that because you try to save money for something that shouldn't cost money at all.

If you don't have very large systems, a staging server is usually a simple VM / container / ....

100k for stage servers wtf is this ?
Probably most of servers are not doing anything.
With fucking tools and possibilities today you can spin off environments in seconds.
Feature flags are cancer.
This article is probably written by some html developer.

@vane people live in their ivory towers made of cloud and forget that big chunk of work that's out there is on-premise "private cloud" if you are lucky and 20 years old IBM mainframe running Cobol and Java 3 if you are less lucky.

@IntrusionCM staging is in my case extact replica of prod, including Oracle running on bare metal. Sure you can replicate database data and anonymize it, how do you replicate real traffic and milions of customers doing weird shit? All you can test below prod is regression really, I'm not saying get rid of staging but true testing happens on prod anyways soooo...

@PAKA I hope you are not trolling me...

There are many ways to test - depending on what you want to achieve.

What you describe is mostly stress testing, which I wouldn't do on a prod server.

It's easy to replicate real traffic, you'll just need to capture it (possibility 1 - logging of select statements).

Since performance might suffer, that's not a smart move in large environments.

Possibility 2: Define workflows.
User A enters Form 1 to execute Search 2.

You can then do the workflow with defined values. Parallelizing by utilizing threads / async and just hammering down with a few 1000 connections.

Possibility 3 is fuzzing. Instead of defining fixed values in a workflow, you'll randomely generate data.

There are _tons_ of libraries out there who can generate _realistic_ data.

Possibility 3 opens the gate for a lot of funky stuff.

You can randomize the form's and hence the values, which is in databases a good way to test many execution plans.

But seeding a database is a good idea, too.

Randomly generating a myriad of rows to test execution plans with large datasets and varying selectivity is for complicated queries like searches a good idea.

@PAKA Today you can buy refurbished blade with 10-20 servers with 20-40 cpu and 250-500gb ram for less then 4000$ on ebay so I still don’t fucking understand how the fuck you spent 100k on stage environment except you’re complete moron.
Hardware is cheap as fuck.
Colocation of whole rack (42U) is what 1k$ per month at most ?
It’s just people are idiots and don’t know how to build and scale systems that’s why cloud is winning. Machine is cheaper then good software developer.

@vane no you can't. You are allowed to buy only hardware that comes with warranty and official support, not everyone is a startup, there is this thing called compliance. Also building has to meet specific security requirements, can't be a basement with air conditioning.

@PAKA you know what’s collocation right ?

@PAKA Curious... What do you mean by compliance?

There is no country afaik who has laws against using a specific type of hardware or a specific setup of hardware.

Unless you are working for the gov / federal offices...

But that's - from experience - a total different universe.

@IntrusionCM Well financial supervison is a bit tricky for example visa and mc won't work with banks who don't meet their standards, also central banks have a say and then finally gouverment comes in. Restrictions imposed by regulatory bodies can range from generic KYC to detailed instructions how our network separation looks like. No strict limitations on hardware or software but having support from vendors is obligatory and not everyone offers that.

@PAKA Still missing which country you are talking about.

But KFC (Know your Customer.... Explain abbreviations when you use them. BAD HABIT!) or AML (Anti Money Laundering) is something else.

And I admit, I've reread your answer 5 times now, and I still cannot make sense of it.

It sounds like you are talking about the financial sector per se...

Which has in general higher requirements, yes.

The last part is most confusing: What do you mean - support from vendors?

Like in HP / Dell / ... business support?

As far as I know, that's a NoGo. Especially in companies with high security no external company is allowed. Only internal access.