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.
Take a look at projects like Discourse, CouchDB, Elasticsearch, Piwik, and Gitlab for great examples of how Vagrant is currently used as part of core development.
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.
Props to Zack Tollman for having this conversation with me several times and to Weston Ruter for sparking it again the other day.
Responses and reactions
I've been working on a fun setup with Vagrant and WordPress (and Puppet) and trying to get it working. It semi-works now but not 100% where I want it.
What I am going for is a WP site that is managed via GIT and through that automatically uses a different MySQL database based on the GIT branch that is checked out. Master would have a DB, 3.5-branch has it's own DB. All of this is driven by the checked out branch in the .git/HEAD file. Since it dynamically pulls the DB name you can easily have a **single** WP codebase with all the themes/plugins shared and to go from testing WP 3.5.2 vs trunk you simply checkout a different branch in git.
I've got that part working with 2 or 3 extra wp-config.php lines which can easily be stored in GIT since Puppet creates and sets the MySQL user passwords but haven't been completely happy with the flow if someone just cloned the WP Vagrant repo and being able to move around in different branches.
Any thoughts on this type of setup vs having multiple WP installs all in one directory? Trying to keep things super simple but at the same time very flexible/extendable.
That's a good question. I think there are a few ways to approach the testing of multiple WordPress versions quickly. I'm inclined to go toward a model where each install exists at the same time rather than switching back and forth. This allows side by side testing in a browser when looking for visual regressions. Would love to test out your current setup and see how it feels.
I was going to suggest firing up another Vagrant VM. But obviously, that's going to waste a *lot* of resources on the host.
But yes, you could handle that pretty easily with some sort of (semi-)automated adjustment of virtual host config, and maybe some additional deployment steps to export WIP from a branch into a "running copy" seen by the appropriate vhost's version of PHP.
The only requirement for your mention to be recognized is a link to this post in your post's content. You can update or delete your post and then re-submit the URL in the form to update or remove your response from this page.
Learn more about Webmentions.