top | item 5559856

A Better Development Workflow with Vagrant

45 points| taylorlapeyre | 13 years ago |taylorlapeyre.me | reply

40 comments

order
[+] bti|13 years ago|reply
Don't know if I understand. You have the one develop box with all the languages/server/databases on there. Then when you decide to start a PHP project, you keep a copy of that box in with the project files? Doesn't this result in multiple boxes sitting around?

Or does the Vagrantfile specify the environment and when you vagrant init develop it recreates it?

I've never used Vagrant but am interested in starting to do something like this.

[+] chewxy|13 years ago|reply
Vagrant is the execution environment that you set up, share and whatnots. Your dev environment (IDE, text editor, etc) can still be in the original environment you are familiar with.

For example, just yesterday, a colleague wanted access to Fork the Cookbook's source (he was supposed to be helping out on frontend javascript). But because some bits of the code is written to be Linux specific, he needed a Linux box while working on a non-Linux box.

So I spent 30 mins creating a Vagrantfile, specifying the environment which Fork the Cookbook runs in. He takes it, runs the env, provisions with the existing provisioning script, and tadah, you get an environment where you get to run the code in.

Due to the synced directories, you can code in whatever env you are hosting on: it's like dropbox between your computer and the virtual box. Network pass throughs allow your host (i.e your physical machine) to use networks defined virtually in your virtual computer.

Great for sharing execution env and getting other people started. Not really necessary if you're working alone IMO

[+] tomku|13 years ago|reply
The Vagrantfile specifies the environment as a combination of a base box, VM settings and optionally a provisioning script/recipe/whatever to run. The base box is only stored once, and individual VMs for projects are created from that box and destroyed when you don't need them any more.

It's common to use something like Chef or Puppet to provision the software that you actually need for each project rather than just put everything in the base box, but the author chose to just make an all-inclusive box instead.

[+] taylorlapeyre|13 years ago|reply
The Vagrantfile specifies the enviroment, and vagrant init develop creates a new Vagrantfile with the base vm specified as "develop".

There's only one box, and you add it to vagrant with "vagrant box add develop path/to/develop.box". After that, you can delete the develop.box file from your computer: it now exists somewhere in the nethers of vagrant's configuration.

[+] tunesmith|13 years ago|reply
I'm still a bit confused - what if you are simultaneously working on two projects that each require a different version of Ruby? Do you have two different vagrant boxes lying around?
[+] jtreminio|13 years ago|reply
I haven't used Vagrant, and I believe I now know why.My daily driver is Win8.I have a Debian VM I do my development on.All files are on the VM because Windows sets all file and folder permissions to 755. This means that if I were to delete the vagrant VM I would also be deleting my files. I am exploring possible solutions to this problem.
[+] limeblack|13 years ago|reply
Similar set up, but I use Cygwin so I can run `startxwin` then run `ssh box -Y` and have have all my applications/workflow running in the Windows taskbar.
[+] AjithAntony|13 years ago|reply
Are you saying that when you share a filesystem between your windows 8 host and the Debian guest, that files written from windows have bad perms?
[+] zjmichen|13 years ago|reply
Pretty similar to my workflow, but why do you destroy the box after every session? `vagrant up` on my laptop takes a few minutes at least to build and provision a vagrant machine.

Usually I just use `vagrant suspend`. Seconds vs minutes. Time > organization IMHO.

[+] brokenparser|13 years ago|reply
Of course, but if you do that please also use a CI tool (such as Jenkins) to ensure the Vagrantfile stays valid. It's actually good to rebuild that VM regularly, especially when it's almost time to deploy.
[+] taylorlapeyre|13 years ago|reply
No particular reason other than freeing up the disk space that the VM uses (which admittedly not much).
[+] dgh|13 years ago|reply
or 'vagrant halt'
[+] pibefision|13 years ago|reply
Anyone has experience using Vagrant with VMWARE?
[+] tjbiddle|13 years ago|reply
They just released support for this the other week I believe (Or at least very recently) - And that is specifically why I've been catching up on everything Vagrant lately, as I was specifically waiting on VMWare support. I asked about it in the freenode #vagrant channel the other day and everyone said it should work the exact same as using the VirtualBox provider - except with VMWare.
[+] juliendsv-mbm|13 years ago|reply
If you have a mac I recommend to have a look at the boxen project from github.
[+] taylorlapeyre|13 years ago|reply
I did actually look into that, but it kind of did the exact opposite of what I wanted. There's a few reasons I'm not too impressed with Boxen:

- Its goal is to install a whole bunch of binaries and development utilities onto my local machine. I want to keep those segregated.

- It only works with Macs. My only computer at the moment is a mac, but it's not always what I use. I use computers at work that are linux based.

- I found that it was buggy. I wasn't very easy to get it actually working. It required a lot of effort and installation.

So, Boxen isn't for me.

[+] artur_roszczyk|13 years ago|reply
I would go even further and store tmux+vim config inside
[+] lojack|13 years ago|reply
I would go even further and use the same provisioning on vagrant as on my production servers so I could set up a mini production environment with whatever dev tools are necessary with just a single command. Recently they added the ability to have multiple machines as well, so all it takes to load up a simulation of my cluster is a single command.