I’ve found the fewer environments a software team has the better. Every additional environment adds cost, management overhead, out of sync risk, and delays deployment. My ideal? Just two environments - Dev and prod. Merge to main auto deploys. Feature flag as needed. 🔥 - ThreadSky

housecor.com • 86 days ago

I’ve found the fewer environments a software team has the better.

Every additional environment adds cost, management overhead, out of sync risk, and delays deployment.

My ideal? Just two environments - Dev and prod. Merge to main auto deploys. Feature flag as needed. 🔥

Comments

uramanovich.bsky.social•85 days ago

The reason behind multiple environments is only complexity to run everything locally.
Good DX for setup multiple projects at once require time, but company prefer invest in 5 envs instead

jamiemchale.com•85 days ago

How do you work a shared dev environment with multiple features in progress? Feature flags? Then dev to main with the flag enabled when a feature is ready?

housecor.com•84 days ago

Yep or ideally a dev environment per dev

nefthy.de•86 days ago

How do you manage QA with only two environments?

housecor.com•84 days ago

Ideally each feature branch gets an ephemeral dev environment with a dedicated short lived URL

nefthy.de•84 days ago

In that ideal scenario, what are your rules for merging feature branches?

housecor.com•82 days ago

Code review passes and PO approves

fredericrous.com•82 days ago

the same as for any other branch? What would be the rules to merge a feature branch in your usual scenario?

brittanyellich.com•84 days ago

In my experience I've seen it where you can get a branch deployed on request, instead of every feature branch. I think deploying every feature branch might get a bit resource intensive.

I've also seen where they're deployed using production data/APIs (more dangerous but also closer to prod).

nefthy.de•84 days ago

Depending on how you do QA it might be necessary to deploy most of not all feature branches.

nefthy.de•84 days ago

I'm currently mostly tending towards doing excessive automated tests and using human QA-engineers more for checking the actual quality of the software. But there's still some way to go, till the test suit is big enough.

fredericrous.com•82 days ago

you mean dev, prod and ephemerals? why keep dev then?

tomaszgil.me•85 days ago

The first company I worked for had 4 or 5 envs. When I later joined places that only had dev and prod, I was terrified.

But it soon turned out it's just fine. More envs added not much more than additional complexity.

mattisig.bsky.social•1 day ago

Generally agree. But as always it depends, heavy applications with alot at stake need more rigurous testing and so they might need more envs... Or?
Starting up/internal app/customer work, sure only two envs 🤷

mattisig.bsky.social•1 day ago

Although ot might make sense for each team. Multiple teams on one app would mean many seperate dev envs (one for each team)?

jonathannorris.bsky.social•86 days ago

100% prod and a pre-prod end-to-end testing environment has worked out well for us. Everything is tested locally then in prod using Feature Flags.

Comments

Posting Rules

Reply