VVV Turns One

A year ago yesterday, I decided I wanted to break up with MAMP.

A year ago today, the Varying Vagrant Vagrants repository was created after an exciting couple nights pounding away at a server config that allowed me to troubleshoot WordPress in Nginx on a local virtual machine.

Since then, VVV has had almost 750 commits from 36 contributors (!!!) on 121 pull requests. The project has been forked 135 times, has 61 watchers and 440 stars.

What a pretty cool year it has been.

Did I mention 36 contributors? On an average of about once every 10 days, somebody decides that VVV is interesting enough to stop what they are doing and submit a pull request containing an improvement.

This blows my mind. Thank you all.

Version 1.0

And now we’ve reached our 1.0 release, which brings us one of the coolest features yet thanks to a wonderful effort from Weston Ruter and Simon Wheatley.

Auto Site Setup

Auto Site Setup allows for projects to be picked up automatically by VVV with custom web structures, host names, Nginx configurations, and provisioning scripts. If you dig into the wiki page explaining how to get started, you’ll get an idea of how powerful it can be.

From a project version control standpoint, it’s fun to geek out about how this came together through a pull request of a pull request of a pull request.

Vagrant Up Just Works

For quite a while, if you ran `vagrant up` on a machine that had been halted, you would also have to run `vagrant provision` in order for all of the services to start up properly.

Version 1.0 is so much happier.

At this point `vagrant up` just works and your workflow can start to match exactly what is expected of a machine that is powered off rather than actually destroyed.

As a side effect of this change, we now copy our config files to the virtual machine from mapped drives on the local machine rather than symlinking them. This may cause some confusion at first if you’re used to changing the configs and having them immediately reflected, but it makes a lot more sense from a provisioning and state management standpoint. This is where `vagrant provision` can be used liberally to reapply any changed config. Commit 1fbf329 contains a more detailed description of the decision and the implementation.

Other Changes

  • Begin implementing best practices from Google’s shell style guide in our provisioning scripts.
  • Databases can now be dropped in phpMyAdmin. Pro-tip, drop database wordpress_develop in phpMyAdmin followed byvagrant provision clears your src.wordpress-develop.dev for reinstall.
  • Allow for dashboard-custom.php to override the default dashboard provided by VVV

Next?

We’re still moving forward. Check out the 1.1 milestone report on GitHub to see what’s in store for the next version and feel free to jump in with pull requests or questions. As part of a greater community of Vagrant users in WordPress, there is also a newer WordPress and Vagrant mailing list that has had some activity. Feel free to stop by and ask any questions there as well.

7 Replies to “VVV Turns One”

  1. As a semi-unhappy current MAMP PRO user, and having read about Vagrant and VVV all day (thanks for all the info!), I do have one nagging question remaining, something which isn’t clear yet. Hope you don’t mind me asking here.

    I can understand all the explanations of how to install and set up a virtual machine server with Vagrant and/or VVV. So after all is done, you have a Virtualbox running with some server setup in it and a dev site in there. But what is missing for me, is how it would fit in/translate to my normal working routine. With MAMP I have like 50+ sites (lost count) running at the same time on my local MAMP stack. All site files for each website/project live in their individual folder inside my ~/sites folder on my mac. ~/sites/project1/, ~/sites/project2/, etc. I can access and work on all those sites at the same time, changing the files and accessing the projects in my browser. Want to create a new website project? Create a new folder inside ~/sites/newproject/, add the new project to the hosts file (using the GUI of Mamp Pro) and I’m done in 30 seconds.

    MAMP is a very lightweight program running in the background all the time, not needing much resources, 80 Mb memory at the moment.

    However, with Vagrant/vvv, do you have a single virtual machine running for all your projects? Or a virtual machine for each project separately? Would that even work? If one VM takes up 2 Gb (?), having 50 of them would take up massive amount of resources. And do you have to start up each VM for each project each time you want to work on it?

    These things aren’t clear at all to me, unfortunately. If you or someone could point me in the right direction for an answer, I’d appreciate it a lot.

    1. It will take some effort to make the full transition the first time, though it will be fairly close to how you have it setup with MAMP.

      Through the Auto Site Setup process of VVV, it is fairly straight forward to add a couple files describing each project to their directory so that VVV can process it as provisioning runs. Each site can live in its own project folder under `vvv-dir/www/site-name/`.

      1. Thanks for your reply Jeremy! I had read about the Auto Site Setup process and will look into it some more, but right now it still seems quite a process. Not bad to do once, but you don’t want to do that a couple of times a day it seems? It’s not entirely clear what the process would look like, if say I already have a few dozen sites running on a server inside a VM, and want to quicly add another one (maybe to start a new project or just to quickly test something). In MAMP Pro it’s just a matter of adding a name for the virtual domain, select the disc folder it will match and push the button to restart the server. Thirty seconds at most. One minute if I also create a new database for the project (in phpMyAdmin).

Leave a Reply