For WordCamp Europe 2015, I was given the opportunity to help a large number of developers get set up for contributing to WordPress Core quickly.
The most cross-platform and standard way of doing this is with VVV — with the only problem being large download size and conference Wi-Fi. Thus, we needed a packaged way to distribute a development environment using flash drives or Adhoc networking.
If you’re in a situation where Wi-Fi won’t be a problem on contributor day, great! If you need a solution for this, read on.
Contents for Contributors
- VirtualBox Installer/Package for their platform
- Vagrant Installer/Package for their platform
- Base VVV ZIP package with Pre-Provisioned box file within
Building a base VVV package
Using a ZIP for VVV is important because otherwise the checkout will have too many files to quickly copy from a flash drive or a local. To build the VVV ZIP package, follow these steps:
- Clone VVV:
git clone https://github.com/Varying-Vagrant-Vagrants/VVV.git
- In the newly-minted VVV directory:
vagrant up --provider virtualbox
This will download the box file and also download all of the dependencies upon first provision. That’s important because they’re about as large as the box file, and account for almost a gigabyte of data.
- To create a base box that includes provisioned packages, run:
vagrant package --output vvv-contribute.box
- Minus the
.vagrantdirectory1, zip the folder’s contents, including the newly-minted box, using either the command line or your favorite file manager.
Contributor Steps to Get Started
- Install VirtualBox
- Install Vagrant
- Copy
VVV.zipto local drive and extract - Add pre-provisioned box to Vagrant:
vagrant box add ubuntu/trusty64 vvv-contribute.box
- Optional, and will download, but manages hosts file:
vagrant plugin install vagrant-hostsupdater
- Start up Vagrant:
vagrant up --provider virtualbox
Caveats
- Once a VirtualBox base box has been added manually from a system, it can’t be automatically updated without removing it, and adding it directly from the web. This means that updates to the Ubuntu base box would need to be done manually by contributors if they want to update later.
- This will not solve all potential Windows issues. While it worked with the majority of machines, there were some Windows users who could not unzip the file with native file ZIP utility, or had other incompatibilities with Vagrant.
Feedback
Have any questions or suggestions? Let me know in the comments!
1 Edit (05/23/2016) – Looks like Vagrant is including the user ID that created the box in a .vagrant directory, which is causing problems for contributors when starting up the box on their local machines.
After attending another contributor day today, even with a decent internet connection, provisioning is still kinda tedious and takes more than I’d want it to.
Here’s an idea how to speed it up. Instead of just archiving the VVV folder, we can run
vagrant package --output=our-awesome-vm.boxand distribute this one alongside a very simpleVagrantfile. In the past we’ve done something similar for the VIP Workshop and has worked very well.VVV stores much of its provisioned content in shared directories, hence the reason for the archive. Without this archive, provisioning takes a long time. With it, everything is pre-downloaded.
I agree that a package that contains this already up to date would be faster, and would love to see a box we can distribute that is particular to core development.
If this approach break auto-updates, how about an alternative approach that gets users to configure their machine to use a proxy, you provide a proxy machine with its cache pre-loaded with the appropriate VVV files & give users the IP address that conference wifi has assigned you. Once they’re setup, remove the proxy config from their machines and they’re good to go with a standard VVV setup.
I’ve thought about this, or something similar, where users download it from a local server.
Assuming conference wifi is up and your machine or server has enough bandwidth (plugged in and gig?), this could work. My concern would be that most conference wifi would fail at this, or at the very least, make it slow enough when all users are attempting to download at once that it would be slower than passing flash drives.
I want it to work (flash drives are not my preferred way to do anything), but would l likely need standardized hardware to pass around between WordCamps for it to work at all of them.
Downloading directly from a local server wouldn’t save you from your first caveat though would it? That was my point about the proxy… it would be semi-transparent and wouldn’t affect the installation’s future upgradability.
But yes – you’ve two problems. A proxy gets around the “flooding the external network link” issue but doesn’t save you from the “residential-grade wifi router” issue.
No obvious solution to the second problem… other than carrying around a gigabit switch, connecting to each developer with physical cable and configuring your laptop as a DNS server, proxy and gateway lol.