4 ms·

Just the other day I was telling a friend of mine how having the ability to share my Vagrant dev environment was the only missing from what I would consider my

by iaskwhy 13y ago

Just the other day I was telling a friend of mine how having the ability to share my Vagrant dev environment was the only missing from what I would consider my dream development workflow. Edit: I got so excited I even forgot to thank Mitchell for all the hard work. Vagrant completely changed my (work) life. Thank you a thousand times, Mitchell!

iratedev 13y ago
How would you use this? I'm racking my brain trying to figure out what this would be used for. I just shared my vagrant file.
- smathieu 13y ago
  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.
- iaskwhy 13y ago
  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.
  - bhouston 13y ago
    > 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
    - iaskwhy 13y ago
      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.
- kasperbn 13y ago
  We use ngrok (vagrant share alternative-ish) to test integration with third-party services that have to send requests to our system. Works great.
deefour 13y ago
I install ngrok[1] on my vm's to show off what I've been working on temporarily or to see how things look on iOS. [1] https://ngrok.com/ https://ngrok.com/
- mitchellh 13y ago
  Localhost tunneling has existed for a long time. It's great if you're already doing it somehow. The benefit of Vagrant Share is that it detects all these ports for you and is basically zero-touch: "vagrant share" and you're done! Another benefit Vagrant Share has that I haven't seen yet in any other localhost tunneling solution is that it shares _every_ port (if you want), not just a single port, and gives the other person an IP to access the machine as if it were on the LAN. This is super nice if you want to expose anything like Redis, SSH, etc. You just "vagrant share" and, again, you're done. Also, many localhost tunneling solutions don't support UDP. We fully support UDP connections in addition to TCP. The big win, though, technology aside, is how if you use Vagrant, this just becomes another part of your Vagrant workflow that _just works_. You don't have to worry about installing anything, and of course it'll work with any sort of guest machine running on any provider.

by iaskwhy 13y ago

iratedev 13y ago

How would you use this? I'm racking my brain trying to figure out what this would be used for. I just shared my vagrant file.

smathieu 13y ago
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.
iaskwhy 13y ago
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.
- bhouston 13y ago
  > 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
  - iaskwhy 13y ago
    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.
kasperbn 13y ago
We use ngrok (vagrant share alternative-ish) to test integration with third-party services that have to send requests to our system. Works great.

deefour 13y ago

I install ngrok[1] on my vm's to show off what I've been working on temporarily or to see how things look on iOS. [1] https://ngrok.com/ https://ngrok.com/

mitchellh 13y ago
Localhost tunneling has existed for a long time. It's great if you're already doing it somehow. The benefit of Vagrant Share is that it detects all these ports for you and is basically zero-touch: "vagrant share" and you're done! Another benefit Vagrant Share has that I haven't seen yet in any other localhost tunneling solution is that it shares _every_ port (if you want), not just a single port, and gives the other person an IP to access the machine as if it were on the LAN. This is super nice if you want to expose anything like Redis, SSH, etc. You just "vagrant share" and, again, you're done. Also, many localhost tunneling solutions don't support UDP. We fully support UDP connections in addition to TCP. The big win, though, technology aside, is how if you use Vagrant, this just becomes another part of your Vagrant workflow that _just works_. You don't have to worry about installing anything, and of course it'll work with any sort of guest machine running on any provider.