Best practices to set up vagrant based development env - same repo as code, different repo, shared folders?

[ni-ka]

Hi,

I'd like to set up vagrant for a couple of projects and am wondering what the best practices are regardings managing both the vagrant files and the code repos of a project. Ideally I'd like a user to be able to set up his development environment by:

- cloning a git repo containing the vagrant config 

- run vagrant

The outcome should be:

- the vagrant vm able to run the project (maybe even running the server already)

- a code folder containing the project code that the devs can point their favourite editor to

Now, having experimented with vagrant a bit, I see the following possibilites

Vagrant in code repo:

I can simply add the vagrant config (VagrantFile and chef-repo as it'll use chef-solo provisioning) to the source repository of the project. The folder containing the VagrantFile thus also contains the sources of the application and editors can simply point their editors to the code repo, which is synced with /vagrant within the virtual box.

For small simple projects with a single code repo it seems like the way to go.

Separate vagrant repo + one or many code repos:

However, what if the project has multiple code repos (multiple application servers, gem dependencies used accross multiple projects)?

I could also create a separate repo for the vagrant config. The source code for the project would have to be cloned by the vagrant provisioner or a shell script. I can add shared folders for different the source code repos.

However, I'd like my cloned vagrant repo to contain all code repo folders (those should not be outside that folder). We could probably use git submodules here, but then some tools don't work very well with submgodules and I'm not sure if developers can just use "git pull" to pull changes, or if they have to use "git submodules update". It might be a nice way to express which version of the vagrant config runs with which version of the code repos, though.

Alternatively, I could also simply check out into subfolders of /vagrant, and use .gitignore file for the subfolders containing the source code repos (or use a subfolder code with .gitignore set to **/*) Not sure if this is cleaner though.

What do you think? How do you manage your repos? What is best practice? Any scenario where the approaches above might not work (ex. trying a new rails version on code repo branch)?

Thanks for your feedback and suggestions!

Nils

[John D. Hume]

We run provisioning and package up the resulting box so that a user of the box doesn't need anything other than vagrant and then to `vagrant add newbox http://example.com/new.box`.

If your provivioning scripts change frequently you could have boxes packaged by a CI server.

I like this approach because a big reason we use vagrant is to allow developers to get up and running with minimal friction.

-hume.

--
http://elhumidor.blogspot.com/
http://www.intentmedia.com/jobs

[Florian Gilcher]

Hi,

we are using such a setup for roughly two years now.

Basically, we do the following:
- Export a NFS share from the box the host (that way, we don't need
vagrant for the box to work)
- Use SSH environment forwarding to port the developers environment to
the box
- we use veewee and puppet in multiple stages to configure the box.
Stages are separated as follows:
* base work (compiling a kernel, nfs configuration, ssh config,
etc.)
* additional libraries and toolsets (editors, things like libxml,
programming languages and build environments)
* project code
- Each of those stages except the last is regularly exported as a
vagrant box to avoid long rebuilding
- project code is only checkout once in the current state and never
touched by provision afterwards
- We have a special repository for our vagrant files

By the way: you seem to be german. Are you based in Berlin? I'm
interested in forming a vagrant usergroup here.

Best regards,
Florian