You may have heard of a hot trend in software development called DevOps. I’m going to let you know how I’ve come to understand this phenomenon, and how it relates to you.
Setting up a local development environment is like camping: You try to replicate the bare essentials of your production server. You have to master a bunch of compact, unintuitive tools. You make several attempts that fail terribly before you start to get good at it. It never really works 100% the way you think it should. DevOps improves this experience, and you will learn to love it.
But What Is DevOps?
In the beginning, there were Developers and Operations. Developers worked on The Application: a website, a program, or a script. Operations, aka IT, worked on infrastructure: the computer given to Developers during on-boarding, or the server hosting The Application.
The line between Developers and Operations began to blur when Operations started developing their own applications. These applications did Ops stuff, like replicate production servers on Developers’ computers, or deploy The Application from developers’ computers back to production servers. Operations strong armed Developers into using the applications they made. Developers, knowing a thing or two about development, put a hand into developing these applications as well, and began bragging about being DevOps.
In short, DevOps programs and scripts manage infrastructure around The Application without actually being a part of The Application. If you:
- Have a script that automates tasks or configuration
- i.e. Ansible, Grunt, Puppet, plain old Bash
- Use niche package managers
- i.e. Composer, Bower, Homebrew
- Use applications that let you replicate your production server
- i.e. Vagrant, Docker
Then you’re in DevOps territory.
What Does Local Development Have To Do With Camping?
A lot actually. Your website or app probably lives on a server, which you can think of as its “home”: secure, organized, all the .conf files, .ini files and thermostats adjusted just right. But when you’re going on coding adventures, you’re not trying to recreate “home”. You just setup the bare necessities to get by.
You’ll need tools: git, a Swiss Army knife; grep, a compass. If you learn how to use them, they’re the most compact, versatile and efficient ways to solve big problems, bar none. But if you don’t learn how to use them correctly, at best they’re useless, and at worst you’ll crash your site/lose a finger.
It takes practice. My first camping trip, I didn’t prepare for rain and everything I brought got soaked. Setting up my first local dev environment, I totaled the operating system and had to reinstall it entirely. I didn’t make the same mistakes the second time, but I did make different mistakes. It feels like wasting time, but you learn skills that are invaluable, and when you make it out alive, there’s a sense of empowerment and triumph.
Finally, No matter how good you get, it never works 100% the way it should. Murphy’s law is in full effect—anything that can go wrong, will. The temptation is to engineer away every inconvenience, but over-engineering can be a liability in and of itself, and you can’t engineer the one thing developers and campers rely upon most: grit. So heed the old saying: prepare, then go with the flow.
Rain or Shine, We’re All in This Together
Keep in mind that the target market for DevOps software is teams: they’re great for individuals, but they really shine when you get organized around them.
You might wonder why you shouldn’t just use XAMPP, MAMP, WAMP or even install Apache, PHP, and MySQL directly onto Windows or Mac. It’s the same reason why camping in your house or yard isn’t really camping. You’re not learning as much, and what you are learning has little to no applicability on a Linux production server.
Finally, we’re all DevOps now. It’s not uncommon these days for new hires to receive a handful of scripts to get their development environments running. This results in a lot of interns scouring forums and IRC for help. Design your setup for novices, and remember that it’s only as usable as it is debuggable.