Workflow and tooling in general is something that interests me a lot. As an independant one-man-show, tooling is an important question, mostly because I can choose exactly how I work, and because I have to choose exactly how I work. Neal Ford’s book, The Productive Programmer, which I read four or five years ago, also helped get me thinking harder about being efficient.
For my development workflow, I’ve become a pretty big fan of virtualization. For most of my projects I have a VMWare image that I can spin up on my desktop and use as a staging server. There are a lot of advantages to this. My primary motivation when I decided to go this route was to be able to separate Apache configuration files for different projects. This was a few years ago, but the Vagrant catch-phrase, “works on my box”, sums it up pretty well. You don’t want to get a couple weeks, or months, into a project before realizing that Project A was depending on a tweak that you did for Project B.
And that is definitely a worthy reason to go this route. But there are other advantages that I didn’t anticipate, so here they are:
Version control This is pretty basic, but if you are livehacking your files on your production server, you are doing something wrong. At the same time you don’t want to have your production files be a Git repository. You need to separate things. A staging server does this.
Automation When I put local virtual servers into my workflow, I had already started using Ant files to build and deploy my projects. Using a local staging server, instead of hacking directly into local files, means that between every edit, when I want to see or test what I’ve done, I have to go into a terminal and run my ant command again. This is a little fastidious (and I should really setup a key in Emacs that calls ant so that I don’t have to move around) but there is a huge, in my view, payoff, in that my deployment automation is constantly being tested. Since most of the build process is identical whether I’m deploying to the staging server or the production server, the system is being constantly tested. When I finally type
ant deploy-live, I am rather confident that things will happen just like on the staging server.
What I’m trying to say, I guess, is that you gain because the entire process is homogenous. Local and distant are the same; you really have one process and two or more targets.
Branching Back when Git (or Hg or Bzr) vs. Subversion flamefests were rampaging across programming forums, one of the main points that people made about Git was that “branching was cheap”. Or easy. Easy, cheap branching makes our lives easier because we can just try something that might be a bad idea – but you never know until you start typing – with the certainty that if we mess up we can quickly and painlessly go back to a known point and start out again with clean slate. This possibility removes stress from the process.
Being able to spin up multiple versions of your project, almost as easily as a Git branch, extends the same idea. “Hmmm, I’m not sure that will work, but let’s try it. I’ll just clone this machine and give it a whirl.” I had a situation like this where I had several versions of a CMS running on different instances, trying to figure out some bug that didn’t make sense.
But more than any particular technical benefit, the important thing about giving yourself quick access to virtual machine is how you think about machines. I remember my early days, before all of this, where changes to the server were risky and stressful, and resulted in crises and downtime. I felt like I was painting a watercolor, or carving marble: one false move and the whole thing is ruined. With virtualization in your life, you don’t think about servers the same way. They are just containers and you are used to setting them up and tearing them down. And because all of this is part of your day-to-day dev life, you are really well prepared when something bad does happen, and you have to move your servers or make some deep, scary change. Virtualization desacralizes the server, and that is good.