New Year's Resolutions For DevOps And QA

2017 is upon us, and so it's that time of year where we all make pledges to better ourselves for the New Year. Whether it's to go to the gym, or to find that special someone, January is the time of year where we sit back, reflect, and set a new course for ourselves. In that spirit, I've put together a list of potential resolutions that should be of interest to readers of this blog.

Containerize Everything

If you haven't gotten around to it yet, make 2017 the year of the container. Containers are an indispensable tool to add predictability and sturdiness to all the pieces that make up your software. When you use containers, you'll produce reliable and consistent failures when your tests fall down, your build fails to compile, or your server goes down. Many common failure scenarios such as "The machine had the wrong version of the dependency" or "Something else was happening on the machine at the same time" can be reduced, if not eliminated entirely, by running inside a container.

Bear in mind, though, that while containers are great - you can build big things very quickly - you'll want to be careful that you don't let the power go to your head. Much as you do when writing tests or considering whether or not to use a 3rd party library, you should think long-term. Think of the expertise required to maintain and manage your container, and whether or not you want to be the one undertaking it. For a simple build script, maintaining the container is fairly simple. Maybe you update and a dependency here and there, then rebuild it. Now think about trying to maintain something like a Selenium Grid. Nodes go up and down, tests leak state, browser and OS versions change, Selenium and its child drivers get updated, and so on. If you've ever tried to build and maintain your own Selenium Grid, I don't have to tell you that it's a lot of work. Take a moment to think, am I trying to build something that's going to require a lot of time and energy to maintain. If the answer is "yes", then perhaps instead of using a container, you should be integrating a 3rd party service.

Virtualize Everything

As someone who's been mucking around with software since the days of the "Turbo Button" and magnetic media, having physical machines around the office can be comforting. The warm breeze of the CPU fan as I compile a large project, the startling interjection of a Mac or Windows boot sound on a machine somewhere at the other end of the room, all contribute to a pleasant ambience of a bygone software engineering shop era.

Be that as it may, I'm finding the reasons and advantages to using them dwindling year after year. Dealing with physical machines is painful and costly, and where you can you should be going virtual. When a physical disk fills up or becomes overloaded, dealing with it is not as simple as running a few commands in the terminal or clicking around a GUI for 30 seconds. With virtualization, it's often that simple. Being virtual means you can scale, recover, and migrate with ease, reconfigure and replicate faster and without downtime, and encapsulate applications while sharing hardware, thus lowering costs. Also, if you're lucky, your hosting provider might even handle a bit of the dirty work (upgrades, security patches, maintenance, etc.) for you.

Speed Up Your Build

We've all been there. You're waiting for the build so you can test the latest fix and then head out the door. Maybe you grab a cup of coffee to pass the time, or if it's really bad, maybe you go for a run or call your mother. Either way, build-time adds up. It adds to frustration and wasted time in the office. This year, love your build. Perhaps, install a dependency management proxy in the office, to lower the time it takes to download all of your dependencies. Break up larger projects into smaller projects or services, so you don't have to build everything when only working with one piece of the application. Convert your project to a build tool that is more friendly towards the parallelization on which today's multi-core machines thrive.

Share Things on GitHub and StackOverflow

I don't have data on how often the average developer Googles any given error message, but I imagine anyone who's getting any work done does it at least daily. While most of the time the first result is a helpful post on StackOverflow, usually containing the answer to your problem in the first 2 or 3 responses, we all frequently encounter questions that haven't been asked or find that the particular solution for your issue is missing. Open a StackOverflow account this year and start answering. Clear your solutions with your company to post to GitHub publicly. Others may thank you later, or introduce you to new and better solutions.

Go Forth

Let 2017 be the year you finally containerize that Python script that the business analyst, who quit in August, wrote - that has now become business critical - but runs as a cronjob on that 5-year-old machine, sitting under the QA manager's desk, that hasn't been upgraded in 3 years (check that machine first when you get hacked!) Let this be the year that you finally buy a space heater because you can no longer open the door to the server room to warm up the office. Call your mother because you have something to tell her, not because you are waiting on Maven. Post your solution to that Safari for iOS 8 / Angular rendering problem only seen in iframes that you've solved with 2 lines of crafty CSS, and for good measure throw in a witty burn at the noob who posted the question in the first place. (OK, perhaps leave out the burn)

We all spent too much time in 2016 investigating irregular failures, dealing with recalcitrant machines, waiting for builds, searching for problems that other people have solved, and coding solutions that we didn't post to GitHub. Let's change that this year!