I’ve been exploring Vagrant lately. At work we need a better development workflow, and at home I’ve been reaping the benefits as well.
One of the nice aspects of Vagrant is the ephemeral nature it gives to your environment. You can spin up a development box quickly and easily with a single command
vagrant up when you’re not working you can halt the virtual machine with
vagrant halt and when you’re not working on the project you can destroy the virtual machine and clear up your resources with
Your environment doesn’t collect clutter from one project to the next. You can tell your clients exactly the settings their server needs, because you know exactly what’s there.
This effectively separates the process of development from the content you’re using. You spin up a box with WordPress installed, add whatever posts you need to build the project for your stakeholder, destroy the box when you’re done. Vagrant up, vagrant halt. Zip up the code and archive it.
But what if a month, or week later, there’s just one more change? Now you have to spin the box up again, that’s easy. But what about that content you needed so you’re designing for content? Isn’t content king? When you destroyed your vm you lost the database.
That’s where this handy vagrant plugin comes into play, Vagrant Triggers. It does what it sounds like. You can now utilize the Sub-Pub pattern in your vagrant config to make sure you can spin up the box just for the 30 minutes you need to make that final change.
Here’s how it works
Install the vagrant plugin:
vagrant plugin install vagrant-triggers.
config.trigger.before :halt do or
before :destroy, whichever works best for you.
In your bash file you’ll want to add:
mysqldump –add-drop-database -u root -p’root’ play < /vagrant/backup/db.sql
You can pipe that into gzip if you want it compressed.
Viola! Now you just need to add to your vagrant up bash something to check if there’s a file to import. (see importdb.sh)