[Chernobog]

> Another common critique is that the pull requests encourage reviewers to only look at the code. They never even pull down the changes they are reviewing!

Our CI automatically deploys a "review app" when someone creates a pull request. This simplifies code review, QA and demoing!

[debarshri]

It sounds cool that you create on-demand review app. In a small scale it works. In a larger scale development is absolute impossible due to resource constraints to create on-demand environment for review app.

For instance, in a warehouse automation infrastructure that has 30 devs, working on 8 feature simulataneously, it is next to impossible to create review app with the resources they need.

[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?

[t-writescode]

At a former company I worked for, every branch would create a new environment with those changes (and some shared components that were owned by other teams); and, if multiple repositories had the same new branch name, it would use all the ones with the same name.

Depending on your system, this is entirely doable.

[twistedpair]

Depends on the app/arch. If you're doing a stateless SPA, the cost is trivial. For example, my org deploys _every_ commit as a preview env. That's thousands of preview envs each month, which we then run E2E automation tests against, to validate each commit.

Using serverless hosting, the hosting bill is < $10/mo.

[tantalor]

Get more resources