[rocky1138]

One thing that's improved our results is asking to see the changes actually working. The person has to demo them live to the reviewer. Many times a small bug or hiccup occurs which would never have been seen by comparing diffs.

[hobarrera]

This sounds like it might work for PRs for huge features, but not every PR. Coordinating a live demo takes more time than it takes to write entire PRs for most cases. Especially if more than one person needs to see it.

[neandrake]

Rather than a demo, we often ask for screenshots or gifs, which has had similar effect of catching some things earlier.

[rocky1138]

This works really well when your team is remote.

[tdumitrescu]

What I dream of implementing at work (once our infrastructure is more fully containerized) is an addition to the CI/CD pipeline where each Pull Request doesn't just kick off tests but also spins up a full staging environment of its own, just waiting for reviewers/designers/PMs a click away. If there were no resource constraints you'd get a separate one for each commit/push so you could compare UX from individual changes.

[deckar01]

You don't have to wait until you migrate to containerized deploys. Last year my team started deploying our project to folders named after the branch and setup one apache rule to redirect all *.dev. subdomains to the correct folder. We call them virtual development environments, and they worked really well with our existing QA process.

[hobarrera]

What about dependency changes (ie: a new package needs to be installed or updated), or database schema updates?

This also sounds very specific (probably using apache+cgi?). It won't really work for most techs out there.

[deckar01]

The deploy script updates dependencies.

We're not using the apache cgi plugin for python to resolve dependencies, just packages relative the the application root. I think most languages that can import dependencies can import relative dependencies.

Although my specific setup may not work for everyone, I suspect that there is an equally simple solution for most projects. Containerization is definitely a long-term goal, but it is not prerequisite for automated deploys. The things you have to change to get deploys to work on an existing server will also be useful for containerization.

[hiphipjorge]

That's pretty much what we provide at Runnable (Full-stack environments for every branch). Every time you create a branch, we create a new environment for you that anyone on the team can access. Definitely helps to be able to play around with the real app! Every time you push a new commit, we update your environment.

Check it out: https://runnable.com/ or contact me if you have any questions.

[hobarrera]

Any plans on providing GitLab support?

[rocky1138]

Nah, it only takes a few minutes for the person to say "I just finished this feature, here's what it should do and here's what it looks like."

[swift]

Ideally you'd have automated tests that must pass before the PR is mergeable.

[rocky1138]

Yes. Those, too.