6 ms·

The idea is that you could have a remote coworker or a QA use your dev server to test things, review UI, etc.

fletchowns 13y ago
So they can only get their job done if they are in the same timezone or if you don't happen to reboot your laptop? Those don't seem like great use cases. Plus if you are at the point of QA/PM review of what you've done, the code has already been checked into source control. They could just as easily spin up their own VM with the Vagrantfile.
- stonith 13y ago
  GP said dev server, not laptop. I think in that context it's reasonable. I used Vagrant for CI builds for a while, and I would have liked the ability to automatically share an internal url to the environment so that when coworkers submitted code that broke the build, they would have a single link to follow to get access to the particular environment on the particular server that serviced their job. Some vagrant envs are also somewhat complex to set up - I could use this for teaching people how to use things like this: https://github.com/stackforge/puppet_openstack_builder https://github.com/stackforge/puppet_openstack_builder
  - fletchowns 13y ago
    But can't you do all the complex/difficult stuff for them so they just have to type "vagrant up"? What are some of the complexities involved in setting up a vagrant env?
- dchuk 13y ago
  You are vastly overestimating the technical abilities of the average QA person. "Just as easily spinning up their own VM with the Vagrantfile" assumes a significant base understanding of a lot of technologies.
  - fletchowns 13y ago
    I think you are vastly underestimating their abilities. You install git, virtual box, and vagrant. Clone the repo and type vagrant up. If they've never done it they can refer to the wiki page you typed up for everybody. I know every QA person at my workplace could easily do it.
    - nickstinemates 13y ago
      I've found there's a broad categorization talent/skills in QA, but a lot of it boils down to this separation -> Able to do development related tasks (set up their own envs, run different versions of apps, etc.) or not. Anecdotally, it also seems to correlate with how useful Developers usually find their peers.

So they can only get their job done if they are in the same timezone or if you don't happen to reboot your laptop? Those don't seem like great use cases. Plus if you are at the point of QA/PM review of what you've done, the code has already been checked into source control. They could just as easily spin up their own VM with the Vagrantfile.

stonith 13y ago
GP said dev server, not laptop. I think in that context it's reasonable. I used Vagrant for CI builds for a while, and I would have liked the ability to automatically share an internal url to the environment so that when coworkers submitted code that broke the build, they would have a single link to follow to get access to the particular environment on the particular server that serviced their job. Some vagrant envs are also somewhat complex to set up - I could use this for teaching people how to use things like this: https://github.com/stackforge/puppet_openstack_builder https://github.com/stackforge/puppet_openstack_builder
- fletchowns 13y ago
  But can't you do all the complex/difficult stuff for them so they just have to type "vagrant up"? What are some of the complexities involved in setting up a vagrant env?
dchuk 13y ago
You are vastly overestimating the technical abilities of the average QA person. "Just as easily spinning up their own VM with the Vagrantfile" assumes a significant base understanding of a lot of technologies.
- fletchowns 13y ago
  I think you are vastly underestimating their abilities. You install git, virtual box, and vagrant. Clone the repo and type vagrant up. If they've never done it they can refer to the wiki page you typed up for everybody. I know every QA person at my workplace could easily do it.
  - nickstinemates 13y ago
    I've found there's a broad categorization talent/skills in QA, but a lot of it boils down to this separation -> Able to do development related tasks (set up their own envs, run different versions of apps, etc.) or not. Anecdotally, it also seems to correlate with how useful Developers usually find their peers.