Skip to content

Development Workflow Upgrade for

A day off means an opportunity to make progress on a redesign. The site (THIS site, save the extremely unlikely event that someone has stolen my content) is old and busted, having been designed and composed by an inexperienced yours-truly, five years ago. The first order of business, before the real work can proceed, has been to update the amateurish development workflow that exists on the site. See previous (quite previous) updates here and here. I’m happy to report that I was just about able to wrap things up today, and will soon be able to move foward with real improvements. code has been pushed into a (previously established, private) git repository on github.

Previous posts describe XAMPP as a way to get a local development environment going, but it was always too hard to configure and keep up to date. Enter Vagrant, which is a wrapper for Virtual Box that makes stable local dev environments effortless. Vagrant is written in Ruby, and depends on dev-ops environment replication tools Puppet or Chef for module configuration of a core Vagrantfile that is like a makefile. I forked a guy’s LAMP Vagrantfile (repo) for my instance here. You will want to muck around with the Vagrantfile to make sure that it uses the appropriate local directory as its web root-I didn’t push my changes back to the public repo. It’s as easy as:

vagrant up

…in the directory with your Vagrantfile to spin up your instance, or just as easy to suspend or shut down gracefully.

With Vagrant, I can point the web root of my local LAMP instance at my local git repo, and edit files under version control, on the fly, and see the results in a web browser pointed at localhost:$PORT (8080, if you’re using my Vagrantfile). Nice! No more editing a file, waiting for it to upload to the server, and then wondering what you might have changed. The Vagrant Getting Started Guide was useful here, as was this blog post.

I am experimenting with the Netbeans IDE today, at the suggestion of a coworker. I had been using the Tower git client for all of my git work. I’m pleased with it, but it makes different assumptions about the status of merge commits than does the Github GUI client, which others on my team use, and that was causing them some problems. I wasn’t able to locate a copy of the Github client for OSX 10.6, which I am stuck on at work for the next little while, so I’m switching over to the command line for my git work. Netbeans automatically and seamlessly updates changes in the file that you’re working on relative to the local git repository, a killer feature that I’ve really been enjoying today in lieu of the GUI git interface. I’ll be switching over to it for most of my work, I think.

For the databases, NearlyFreeSpeech allows remote MySQL connections only through an SSH tunnel, so that needed to be set up before DB access from Vagrant would be possible-this was a little conceptually tricky because you first need to ssh into the Vagrant instance and set up the tunnel from there. This blog post was helpful-I know I’ve had trouble setting up the tunnel for NFS before, hopefully it will stick this time. You wouldn’t want to (or be able, per NFS policy) run production SQL queries through a PHP CLI SSH tunnel, but for this instance you can set up the tunnel in a terminal and then just go to town. I’ll have to maintain dev/prod DB authentication differences in my code base-that will be one of the few concessions to the differing environments.

For deployment, I had previously set up a staging account on NFS with its own separate MySQL instance. I added staging and production repositories as remote branches to my local git environment, then followed this method for easy deployment: added a post-receive git hook with a hard reset, which will return the server-side repository to the head with the latest commits that I’ve just pushed as they come in. Now I can do:

git push staging master

…on my local git instance to verify server-side in case the minor differences between Vagrant and NFS are catastrophic, then

git push prod master

…if all is well.

I can now work locally and instantaneously on versioned files in a nearly identical local environment to my production environment (and it could be easily and maintainably identical if I dug down into it, but I don’t think that will be crucial for my uses). I can push my changes to a remote development repository on github, as well as push my local environment configuration changes to a remote repository-if my local machine goes down, nothing will be lost. I can get one-step deployment to staging or production.

I’m still missing a plan for database replication, but that’s not a huge priority for how I use these databases. With this updated deployment workflow in place, I’m ready to get this website in shape! Probably not the part that you’re actually reading, though-I’m still a fan of this WP theme.

Post a Comment

Your email is never published nor shared. Required fields are marked *