4 ms·
> because reviews with live code are always better than code-only reviews. Always? I don't know. The author is responsible for testing and deploying the PR, n
by redis_mlc 6y ago
> because reviews with live code are always better than code-only reviews.
Always? I don't know.
The author is responsible for testing and deploying the PR, not the reviewer. Also, in devops a lot of changes affect production, so cannot be fully tested until deployment.
It sounds useful for seeing UI changes, but the closer you get to the backend, the less visibility there is.
Or in companies with "political issues" like multiple groups with boundaries between development, test, and operations.
Maybe the PullReview people can add some use cases?
- crohr 6y agoHi, thanks for commenting! The idea here is not to skip the code review, but augment it with a way to experiment with the feature as early as possible in the development process. It’s particularly useful for product owners who may not be coders and want to give feedback on how the feature aligns with the vision. It’s also useful for other developers because seeing the thing live will give more context as to what the feature does and how it behaves, and as such might help reviewing the code and get reviews other than « good to merge » without any meaningful comments. And finally it’s also very useful in making sure every dev can do a little QA on their feature in a standardised environment that runs with non-dev setting, without waiting for a staging server to be available. The 80/20 rule most likely applies here. For some PRs you won’t need preview environments (just don’t add the label), but from my consulting gigs I have experienced more than once the need for this kind of tooling, and also witnessed more than once how many companies try to reinvent their own thing and the time they spend/waste doing so.