5 ms·

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

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 10y ago
Rather than a demo, we often ask for screenshots or gifs, which has had similar effect of catching some things earlier.
- rocky1138 10y ago
  This works really well when your team is remote.
tdumitrescu 10y ago
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.
- hiphipjorge 10y ago
  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/ https://runnable.com/ or contact me if you have any questions.
  - hobarrera 10y ago
    Any plans on providing GitLab support?
- deckar01 10y ago
  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 10y ago
    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 10y ago
      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.
rocky1138 10y ago
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."

neandrake 10y ago

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

rocky1138 10y ago
This works really well when your team is remote.

tdumitrescu 10y ago

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.

hiphipjorge 10y ago
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/ https://runnable.com/ or contact me if you have any questions.
- hobarrera 10y ago
  Any plans on providing GitLab support?
deckar01 10y ago
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 10y ago
  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 10y ago
    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.

rocky1138 10y ago

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."