Well, this came to my mind because I'm developing a new responsive web app and wanted to test it on both my iPhone and iPad. There are several ways around this but I guess this makes it so much easier.

Also, as noted, seems great to let your colleagues see what's going on with your work.

> I'm developing a new responsive web app and wanted to test it on both my iPhone and iPad.

This is already easily done just by configuring port forwarding from your host to your guest in your vagrantfile.

e.g.:

config.vm.network :forwarded_port, host: 8080, guest: 80

I'm not sure that's the way to do it. I mean, I do use forwarded ports on my projects and I also configure my private network for each one but at least on my current machine it doesn't allow outside access unless I mess with the router and the firewall. A little bit easier would be to configure a network as "public_network" on the Vagrantfile. I assume this works for most people but, again, my machine doesn't vagrant up if I have a public_network configured. I never tried to figure out why, it's not something I had to care about that much to be honest.

So, as you can see, if vagrant share works as announced it would make it much easier for me for that particular task.

We use ngrok (vagrant share alternative-ish) to test integration with third-party services that have to send requests to our system. Works great.

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

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.

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

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?

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.

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.

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.