We don’t use a staging environment
squeaky.ai
We don’t use a staging environment
1–10 of 357 posts
Re: We don’t use a staging environment
#2This sounds horrible unless they have a super reliable way to roll back changes to a consistent working state, both in their deployments and their databases.
Re: We don’t use a staging environment
#3This makes some sense for a single application environment. In our system, however, there are dozens of interacting systems, and we need an integration environment to ensure that new code works with all the other systems.
Re: We don’t use a staging environment
#4This sounds horrible unless they have a super reliable way to roll back changes to a consistent working state, both in their deployments and their databases.
Agreed, this sounds crazy. One argument raised is because staging is often different from prod. But their laptop are even more different. It seems the main goal was to save money. All this make sense only for a very small team and code base
Re: We don’t use a staging environment
#5This strategy won't scale beyond a very small team and codebase. The reasons mentioned, such as parity, are worth fixing.
Re: We don’t use a staging environment
#6> We only merge code that is ready to go live
That’s a cool April fool’s squeaky.ai
Re: We don’t use a staging environment
#7No post body was provided.
Re: We don’t use a staging environment
#8This is pretty common actually
At Facebook too there was no staging environment. Engineers had their dev VM and then after PR review things just went into prod
That said features and bug fixes were often times gated by feature flags and rolled out slowly to understand the product/perf impact better
This is how we do it at my current team too…for all the same reasons that OP states
Re: We don’t use a staging environment
#9Infra as code + good modern automation solves the parity issue. I empathize with wanting to stay lean but this seems extreme.
Re: We don’t use a staging environment
#10This sounds horrible unless they have a super reliable way to roll back changes to a consistent working state, both in their deployments and their databases.
You really need to use canary deployments/feature flags with this style. i.e. release to production but only for a group of users or be able to turn a feature off without another deployment.