Plenty of changes and plenty of contributions this round. Great stuff!
Some Windows machines were having trouble with the SVN portions of Varying Vagrant Vagrants, getting this error during an svn checkout:
svn: Can’t move ‘.svn/tmp/entries’ to ‘.svn/entries’: Operation not permitted
Such an ugly thing to have to troubleshoot, but we had several minds at work.
Many sites indicated there was some kind of file permissions problem between Virtualbox and Windows. One of these sites happened to mention the issue being related to the version of SVN.
Long story short. If you end up here because of SVN issues in Vagrant or Virtualbox, upgrade to SVN 1.7 or higher inside the virtual machine and see what happens.
Varying Vagrant Vagrants started off 4 months ago as a shot in the dark to solve a problem I was having. As development progressed, it became immediately clear that this was something we wanted to have in the 10up bag of tricks while we’re working with varying production environments. The contributions from other 10uppers have been fantastic and it quickly became obvious that this should grow in 10up’s area of GitHub rather than in my little personal corner.
Things have come a long way and we now have a great base to start branching from. The next hope is to see custom Vagrantfiles from groups like WordPress.com, ZippyKid, WPEngine, DreamHost, GoDaddy, Bluehost, or anybody else doing WordPress hosting.
We’ll keep the pressure going on that front and over the next few days do a better job of explaining the overall goal for Varying Vagrant Vagrants, how we’ll use it internally, and how you may be able to use it or a variant for your own development process.
In the meantime, if you’ve already cloned the repository, please make sure that your git remotes are up to date if you’d like to pull in changes.
Over the last few months I’ve been planting seeds with every WordPress developer I run into with the hope of convincing them to use Vagrant to manage their development environment. The basic pitch has evolved with time and now that I’ve had the chance to fine tune it for 10up’s recent developer summit, I’m going to lay it out here as well.
It helps to start with what we’ve been working with so far. The first step to developing for WordPress is to make sure your environment meets the minimum requirements. As of today, these are PHP 5.2.4 and MySQL version 5.0 or greater.
The beginning of WordPress development was often like the wild west. Cowboys abound, PHP files were edited in some form of a text editor and uploaded directly to the server for testing. White screens were a good indicator when things went wrong.
As familiarity with WordPress, PHP and MySQL progressed, local LAMP environments arrived. Apache, PHP and MySQL all had binaries that could be installed in Windows or Mac and a basic development environment could be setup with relative ease. White screens now happened locally first and more rarely in production.
MAMP, XAMPP and WAMP came along and provided a few click method of creating a stable LAMP sandbox for us to play in. With the minimum requirements for WordPress development met, things got stable and stale.
Rather than meeting minimum requirements, Vagrant provides a flexible way for a developer to meet environment requirements.
How about a server running Ubuntu 12.0.4, nginx, PHP-FPM, MySQL, memcached and the PECL memcache extension? Vagrant does that.
And CentOS 6.4 with nginx, PHP-FPM, MySQL, memcached and the PECL memcached extension? This too.
Or Debian 6 with page caching provided by Varnish or Redis… Can also do.
But wait.. still working with that project hosted on Apache, MySQL and PHP?
Vagrant does that.
This matters. The closer you can be to your production environment during development, the more confident you can be that the code you are pushing has been tested properly.
When that tricky cache expiration issue appears, the tools will be immediately available to confirm and troubleshoot it. When somebody on your team needs to jump in to help on a project, only a couple commands stand between them and a full matching system.
And at the end of the day, when you are done with development, one command powers off this amazing virtual environment and leaves you with a personal computer.
10up has a pretty decent setup going over at Varying Vagrant Vagrants. A walkthrough from a few weeks ago is up at Evolving WordPress Development With Vagrant. We’re continuing to cruise ahead with a common nginx, MySQL, PHP-FPM and memcached setup, but we’ll be branching off to our other environments shortly as well. If you have an environment you’d like to see matched, fork the repository and give it a go.
Hi!
What we have in our default provisioning so far is pretty close to a basic version of the WordPress.com server environment. We would love to help create a Vagrant setup that matches production as closely as possible and can be used by anybody developing a project with that in mind. Ping me when you’re game. 
Cache issues be gone!
Among the changes:
In the last 3 months I’ve been hacking away at various Vagrant configurations. A look at uniques in my bash_history is fun:
164 vagrant up 115 vagrant destroy 42 vagrant halt 17 vagrant resume 15 vagrant suspend 6 vagrant reload
Yesterday we tagged version 0.2 of Varying Vagrant Vagrants, an evolving Vagrant configuration with an end goal of providing a system to pass development projects between team members at 10up for easy ramp up on projects. While any development project can be supported, our initial focus is WordPress. If you’re doing any kind of WordPress development, you should check it out. If you check it out and you fall in love, you should think about working with us.
UPDATE 04/12/03: This post is a great intro and provides good context for the overall Vagrant discussion that’s been happening. Quite a bit has changed in the last few weeks and I would recommend stopping by Hi WordPress, Meet Vagrant for some of the latest fodder. Thanks!
Vagrant is an open source “tool for building and distributing development environments”. Created by Mitchell Hashimoto, it provides a method to automatically provision a headless virtual machine for use with virtualization software such as VirtualBox. The various configurations of these virtual machines are sandboxed away from your local machine.
VirtualBox is open source virtualization software from Sun Microsystems. It provides a method to handle these prepackaged virtual machines, or boxes, that are configured with Vagrant.
Varying Vagrant Vagrants is an exploration into the world of of Vagrant and how it can help to make development efficient and in sync with production systems. It replaces the common MAMP or XAMPP setups that we have become familiar with and ensures that all members of the team can develop in the same environment for a project without worrying about the operating system on their local machine.
One development environment is currently provided with Varying Vagrant Vagrants. This includes Ubuntu 12.0.4 with Nginx, PHP-FPM, MySQL and Memcached. While this does not match every production environment, it has become a very common setup for highly scalable WordPress sites. It is these sites where developing in sync with production can be the most important. The closer we can come to matching the exact environment, the more likely we are to catch bugs and environment specific situations before deployment.
Getting started is easy, and will more than likely take you less than 30 minutes.
With that, your virtual machine is running. Test it immediately by going to 192.168.50.4 in a web browser. To start working with WordPress, one more step is necessary.
Once mapped, visiting `local.wordpress.dev` in your browser will bring up an initial WordPress installation. Follow through that to create your first WordPress development environment in Vagrant. Themes and plugins that you are developing can go into the respective `www/wordpress-default/wp-content/` directories.
From here, you should experiment.
If you are familiar with object caching, the common plugins for working with PECL memcache can be installed. Memcached itself is already installed and running for when you’re ready.
If you start poking around the internal documentation for Varying Vagrant Vagrants, you’ll see quite a few places where you can hook in with customizations of your own to continue to extend the development environment.
Two goals are driving the development for the next releases of Varying Vagrant Vagrants.
Please feel free to pass along any feedback or issues with the current release via the GitHub issues page. Any input is much appreciated!
If you want to geek out on some context for my Vagrant experience so far, check out these posts:
Note: I’ll be giving a couple of talks about getting started with Vagrant over the next couple months and I intend for this to be a decent description covering some of the basics those who are attending should complete. If are planning on attending in PDX or Seattle, please read this through and complete the steps as best you can.
I wrote an initial blog post a couple months ago that highlights my fascination with Vagrant and may help give a broad overview of the problem I was trying to solve. Keep in mind that I went from eager excitement to mind blown user of Vagrant within 24 hours. This will be you.
Now, ignore everything there and start from scratch.
VirtualBox is an open source (GPL) cross-platform (that’s everyone!) virtualization application. Oracle provides a great overview in its first steps documentation here - https://www.virtualbox.org/manual/ch01.html
Vagrant is an open source (MIT) tool that allows you to setup one or multiple development environments on your local machine that are sandboxed away from your operating system. The getting started guid describes it best:
“Vagrant uses Oracle’s VirtualBox to build configurable, lightweight, and portable virtual machines dynamically.”
I’ll go into much more detail during the presentation, but this is a good start.
Vagrant is best explained when you are already up and running with it. To best be prepared for the meetup, it would be great if everyone had the following completed.
And you’re ready! At this point, don’t worry about screwing anything up. As long as you have VirtualBox and Vagrant installed and the 600MB box cached to your machine, interacting with the box during the meetup will be a breeze.
See you soon!
Fooled you. You think that cache is the problem, but it’s not.
Scenario 1… You installed Vagrant with VirtualBox on your local machine and have a sweet nginx setup going as your development environment. You made a few changes to a CSS file and the new style is not reflecting on the page. You try saving the file again in your text editor, no go. You look at the file on the server, it’s cool. You restart the nginx service, still no change. You restart the services for php5-fpm and memcached, maybe even mysql… no go.
Something has captured this file in cache and is not letting go!
Scenario 2… Same setup. You made a few changes to a JS file and the script doesn’t seem to be working. Must be a caching issue. You try saving the file again, look at the file on the server, restart nginx, restart everything. Finally look at the console in your browser and see some kind of random error.
Sooner or later, with one of these files, you open it up and see these:
�����������������
What the what? It’s an encoding issue? Not a caching issue? Or it’s a… wait, what?
Hopefully you haven’t spent too much time trying to figure this out before stumbling on a site like this one that tells you the only change necessary is a simple line in your nginx config file.
sendfile off;
Find the spot in your assorted nginx config files that says ‘sendfile on’ and change it to ‘sendfile off’.
Sendfile is used to ‘copy data between one file descriptor and another‘ and apparently has some real trouble when run in a virtual machine environment, or at least when run through Virtualbox. Turning this config off in nginx causes the static file to be served via a different method and your changes will be reflected immediately and without question – or black question mark diamond thing.
Hope that saves you a minute.
For further reading, consider those that have stumbled on the same problem before.
Or, even better – more detail about sendfile itself and other common nginx pitfalls:
I decided yesterday that I wanted to break up with MAMP. While it (and XAMPP) have served their purpose well over the last year or so that I’ve been using them on a regular basis, they don’t come close to mirroring some of the most common server setups out there today for the development that I’m doing.
I want to break up with MAMP.
— Jeremy Felt (@jeremyfelt) December 10, 2012
Most of the smarter setups for PHP dev these days include some combination of nginx, mysql, php-fpm and memcached – at least. The thought of trying to get all of these packages installed and working on a local OS X machine is overwhelming. This computer of mine should be a laptop, not a server.
Luckily, I’m not alone in this dilemma and I got a couple of great replies right off the bat. One came from Tom Willmot pointing me toward some fantastic onboarding docs for Human Made on GitHub that walk through setting up services in OS X. I started down that path because it looked great, but I was also tempted by a reply from Micah Godbolt asking if I had been keeping an eye on Vagrant. That temptation ended up winning the night.
Enter the virtual machine.
I had heard of Vagrant briefly, but had never given it a full chance. I was probably in one of those modes where I would move on if I couldn’t figure it out in less that two minutes. This desire to break up with MAMP finally gave me the will power needed to put in more time.
It turns out that Vagrant is freaking wonderful.
And just over 24 hours later, I have my first draft of a provisioned server up on GitHub as Varying Vagrant Vagrants. It’s fantastic.
I am now able to fire up an instance with a simple ‘vagrant up’ that automatically installs nginx, php-fpm, mysql before proceeding to move config files around and import SQL dumps so that just minutes after the initial command, I can go to an existing dev site in my browser or initiate a brand new WordPress install.
Sold.
So now I’m on the hunt for more. I’m going to head over to the Portland Drupal User Group meeting tomorrow night for a demo on Vagrant and Puppet and I’m now hoping to start filling my brain with everything Vagrant. There are so many possibilities for sharing dev environments with team members and I can see this turning out to be a ton of fun.
With all that said, get over to GitHub and fork Varying Vagrant Vagrants to see for yourself. I’ve done my best to include some documentation that should get you all the way there, but feel free to reach out if you need some help.