3

So I've been working with Vagrant and I find it to be excellent but I'm wondering what the best or most common use of it is

I imagine that there to be two ways to use it: The first would be to create a kind of master repo that contains the Vagrant info and puppet scripts for the a development environment for that organisation. This would have the benefit that there could be multiple repos that use it in a common way.

The second would be to create a vagrantfile per project that is reflective of that particular project.

The second seems like the way that I would try and structure things but I'm wondering if there are pitfalls with that approach.

1

This is kind of a loaded question, but I really hate when people remain super vague and try to sound all intelligent about a topic, so I'll try to write out my plan with a few thoughts. It really depends whether you're working on a variety of different types of servers, or only a single type. Also, if you're fiddling with provisioning for some reason or another, this could increase the need for a per project basis.

For me? I Like things in templates: Code, life, budgets, shopping lists, frying pans, etc.. I am an engineer and I like things abstract and generalized that are reusable and extensible.. So for vagrant, I'd want one primary vagrant project repo with the provisioning tool I prefer (puppet). I would have different versions of this abstracted and generalized as I saw fit per project. If my company did hundreds of wordpress sites, i'd make a default setup that started up a server and installed the latest (or x) version of wordpress, and similar for whatever other projects that aren't rarities (Symfony, RoR, Laravel, node).

When starting up a new project, you would initialize the new repo for your project, and then add a submodule for the closest generalized vagrant project for your needs. Developers could then edit the vagrant submodule, and either not push changes, or push changes if they were large enough changes to require updating.

I would be sure that developers who had a need to update their vagrant repo did so by creating a new branch. I would have git hooks on the vagrant repos that notified lead devs of changes, so they can review and determine necessary steps for further abstracting out projects. Can we create a new vagrant repo based off the changes for this specific project? Is it important enough?

This flow should ensure we can have control of our git history for the sake of reviewing projects in the future to determine their "base" vagrant setup, allows us to easily update and correct any bugs that existed in our base vagrant projects, and allows all projects to be able to update their vagrant submodule's easily without impacting their project code.

Anyway, that's my idea for how I plan to do it if I ever get around to it.

  • thanks for sharing. This is a new approach that I hadn't considered. – Mr Wilde Apr 7 '14 at 20:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.