[fletchowns]

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]

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

[fletchowns]

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]

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]

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]

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.