Hacker News Reader

Comment by Negitivefrags | Hacker News Reader

If you are saying you don't have a staging environment, what you are really saying is that your company doesn't have any QA process.

If your QA process is just developers testing their own shit on their local machine then you are not going to get as much value out of staging.

View on HN

I’ve worked with multiple teams where QA tests in prod behind feature flags, canary deploys, etc. Staging environments and QA don’t always go hand in hand.

I've seen this before at very large companies. All testing done in local and very little manual smoke testing in QA by either the PM or other engineers.

There are big tech companies that don't have QA people.

But you don't need to have a single staging env shared by all QA testers. Why not create individual QA environments on an as-needed basis for testing specific features? Of course this requires you to invest in making it easy to create new environments, but it allows QA teams to test different things without interfering with each other.

This worked reasonably well as v-hosts per engineer, though it did share some production resources. QA members would then run through test plans against those hosts to exercise the code. I prefer it to a single monolithic env. Though branches had to be kept up to date and bigger features tested as whole.

No, it says if you have a QA process it doesn't including a staging environment.

A QA process is just a process - it doesn't have necessary parts - as long as it's finding the right balance between cost, velocity, and risk for your needs, it's working. Some parts like CI are nearly universal now that they're so cheap; some like feature flags managed in a distributed control plane are expensive; some like staging deployments are somewhere in the middle.

> If you are saying you don't have a staging environment, what you are really saying is that your company doesn't have any QA process.

Come on - this is nonsense.

Feature flags for example?

Feature flag systems don’t magically prevent a new feature from causing a bug for other existing features, or even taking the whole site down.

Speaking as the guy who pushed for and built our staging environments, neither do staging environments. (Speaking also as the guy who has taken the whole site down a few times.)

That's absolutely not true.

You can just compartmentalise important changes behind feature flags / service architecture and test things later.

Reply on news.ycombinator.com