Vagrant is a very refreshing tool.
Once the Vagrantfile and provisioning of a project is setup, new developers can join a project and start developing immediately without worrying much about a local setup. DevOps and sysadmin folks can continue to tweak servers and various configurations, passing those changes on to the development team without interruption. Over time, the local development environment comes closer and closer to matching the project’s production environment and those annoying bugs that creep up when the two are different start to disappear.
A bunch of people in the WordPress community have done a ton of great work with VVV over the last 7 months and it’s great to see the traction that it’s gotten. It is a great example of a very useable and modern WordPress production environment and I think will continue to go a long way toward upping the game of many.
An open source project that ships with a default Vagrantfile is very refreshing.
The barrier to entry becomes so low. Within a matter of minutes, a virtual machine can be launched that provides the operating system, server software, and configuration needed to get started with development and to view the results of the changes that you are introducing. This gives everyone developing for the project a common baseline, helping to avoid worksforme bugs and allowing things to progress faster.
Now. Imagine a WordPress core that ships with a Vagrantfile of its own. Anybody wanting to contribute to WordPress or to work in an optimal environment for building a plugin or theme that can run on any WordPress installation would have the ability to use a virtual machine that the community has decided is valid for development and comprehensive testing.
The possibilities of what could be included in that environment are pretty slick.
- WordPress Unit Testing is one of the coolest things that VVV currently provides. Giving anyone who wishes a unit testing environment without having to worry about installing PHPUnit locally would go a long way in getting more WordPress developers to test.
- Scripts that generate core documentation on the fly can be included with the Vagrant configuration, helping developers to explore the core code base more on their local machine.
- Tools and guides for patch creation, even scripts that automate some of the processes that come with Trac interaction, would help lower the barrier to core contribution.
Granted there are hurdles.
WordPress, along with most other PHP projects, is forced to support multiple versions of PHP. And while web server versions don’t matter as much, it’s still nice to know that both Apache and Nginx are working well, especially when various issues are being dealt with in the world of rewrites. That said, there are ways to provide a flexible environment that can accomplish all of this.
And when we do!
Being able to switch from PHP 5.2 to 5.5, from WordPress 3.6 to trunk, or from Apache to Nginx on the fly to make sure your plugin is compatible with each will be an absolute dream.
All achievable with two steps: Check out WordPress, type vagrant up.
Grand ideas aside, the first goal is to exist. I’ve started a new repository on GitHub, WV, and it would be wonderful to start discussing how this world looks now. I’d love to hear ideas on what provisioner should be used, what features should be started with, and how we can approach making this part of WordPress core.