[Chernobog]

I'm not going to dismiss your experience, or your knowledge about the environment you describe, but we are most definitively not doing small scale development. Our company has a large software stack comprised of several backends and frontends, maintained by 8+ teams.

I maintain one frontend in this stack, and the review app produced will only contain my version of the front-end, and the API calls will go to the backends in the development environment.

Review apps for backend services will also point to the development environment if this particular backend needs to communicate with other services.

When a feature touches a frontend and a backend simultaneously, we can solve that in various ways. Sometimes the backend can be finished first, but if that's not feasible we can supply URL overrides for endpoints to the review app of the frontend, so it communicates with the review app of the backend (and uses the rest of the development environment for the other calls).

This works for us and might not be feasible for all projects/stacks/companies for various reasons. YMMV I guess :)

[debarshri]

You are looking at a problem from developer's perspective. From infrastructure perspective, it is a terrible pattern if you own the feature-flow or review app flow. It is really wasteful with no guarantee that when all the features that are written concurrently are merged, it your feature will still work as expected.

Let me put it in another way, would it have been if you would have kept, development, test, staging and production environments up to date all the time and had meaningful integration tests?