[podoman]

Most of our users are using Reploy for the concept of "Preview Environments". That is, being able to view the environment before a merge happens.

In fact, in many cases, it doesn't make sense to do a full production deployment on every PR (either from a time or cost perspective).

I do, however, understand your hesitancy regarding having a different deployment structure for these previews. The reality is that if you want fast builds an experience that makes it easy to compare different commits, etc.. there is a tradeoff.

[dpix]

Yep! that is exactly what our system also does. QA sign off and automated tests run against our preview env. We aren't pushing PRs to prod.

It's just hard to justify the validity of a preview env if the deployment is different to that of prod, the deployment and infra is part of what you test IMO.

   The reality is that if you want fast builds an experience that makes it easy to compare different commits, etc.. there is a tradeoff.

What makes you say there needs to be a tradeoff? If you can deploy these preview environments so easily why can it not be the same for production too?

I actually think this is a great sounding product. I've pushed in almost every company I've worked at in the past to have per PR environments but never actually had it working for real until my current workplace and it is fantastic. It's for sure made easier with the use of serverless and/or container

[podoman]

Hello! I'm slightly confused here, but I do agree with your statements.

Are you implying that Reploy should also support production Deployments? If that's the case, then yes! We're also thinking in that vain more long term. I personally feel like existing solutions have their downsides, and there's a lot of room for innovation in this space :).

Regarding the tradeoff, I'm mostly referring to existing large companies that have lengthy deployment pipelines. For them, Reploy is a good solution to "preview" changes before they go into production.

> It's just hard to justify the validity of a preview env if the deployment is different to that of prod

For the "preview" use case, it often makes sense. i.e. I just wanna make sure that a button works or something. But I do agree that the production/integration-testing similarity is missing here. This is where the Reploy for production idea is strengthened.

Last point: For really big companies, there's no way that their prod infrastructure would fit into a Preview environment. This is where Reploy (only staging) proves itself being a valid product on its own.

Sorry if my thoughts are jumbled, but really appreciate the interest/questions.