Six essential software deployment tools for error-free applications

By Mitchell | Posted Jul 16, 2017 | 3 min. (603 words)

Bad deployments are a resource-draining problem for every development team. Without the help of software deployment tools, spotting a bad deployment is like finding a needle in a haystack.

Almost 1/3 of software businesses count on their end users to report these errors. In the last company I worked for, we’d deploy, wait a day or two, and assume it was all fine because we didn’t hear many complaints.

What we didn’t factor in was that only 1% of customers report software errors, and any reports were usually vague and never gave diagnostic details. But we didn’t know a better way.

In truth, our development pipeline could have been better automated to avoid bad deployments and detect errors – without relying on our customers to tell us.

Firstly, what is a”bad” deployment?

Warning signs of a deployment that has caused problems

Increased P99 load time
Customers taking to social media
Higher error rates
Shorter customer sessions

I’m not saying wait until your deployment is perfect. Imperfection is part of the continuous delivery process. In our devlopment team, we say:

“Move fast and break things – just fix them quickly.”

You may be thinking that just one bad deployment can’t have that much of an effect on business. An example of a terrible deployment happened on Wall Street just a few years ago. The Knights Capital Group lost $400 million in assets and went bankrupt in just 45 minutes because of a single failed deployment. It sounds too bad to be true, but this particular deployment caused complete havoc:

“During the deployment of the new code, one of Knight’s technicians did not copy the new code to one of the eight SMARS computer servers. Knight did not have a second technician review this deployment and no one at Knight realized that the Power Peg code had not been removed from the eighth server, nor the new RLP code added. Knight had no written procedures that required such a review.”

SEC Filing | Release No. 70694 | October 16, 2013

In a post deployment analysis, DevOps expert Doug Seven advises two principles that could have prevented the collapse of Knights Capital:

Releasing software should be a repeatable, reliable process
Automate as much as is reasonable

It’s common to believe that disparate tools are expensive and unnecessary. However, that cost is negligible compared to the cost of not integrating tools to aid the deployment process. Below I’ve highlighted six essential software deployment tools that will make your deployment pipeline both more reliable and repeatable, with a few examples.

In Knight’s case, error reports highlighting the bad deployment landed in employee’s inboxes but weren’t marked as “critical,” meaning the emails went unopened. Crash and error reporting distils error reports into just one digest.

While crash reporting is great for critical problems, it doesn’’’t tell the complete story of other non-critical problems that frustrate customers. What can you do to tell a better story of a customer’s experience?

It’s all about having your software tell you what’s wrong, so your customers don’t have to. As Doug Seven explains: “It’s not enough to build great software and test it; you also have to ensure it is delivered to market correctly so that your customers get the value you are delivering (and so you don’t bankrupt your company).”