.svg)
If there is any bright spot in the recent COVID-19 mess, it is software’s ability to connect the world and enable nearly every major facet of modern life to persist, despite awful circumstances.
But when software fails to work as expected, the negative implications are worse than ever. The gravity of even a single application error slipping through to production can be catastrophic, as we saw with the recent Zoom outage.
Most organizations have already invested heavily in various testing measures, so what else can be done to maintain software delivery speed without allowing escaped defects? Automated code analysis could be the answer.
But what are static and dynamic analysis, and why should you consider using them? Below, we break down the unique value each tool provides and why you might consider adding them to your DevOps toolchain.
Let’s start with a sporting analogy to help illustrate the difference between these two methodologies. Static code analysis is analogous to practicing your baseball swing with a practice net and a pitching machine. There are minimal surprises. After a few swings, you know exactly where the ball is going to be every time. This helps to work on fundamentals and to make sure that you have good form. While this helps with improving your game, it can only get you so far.
Dynamic code analysis is more like practicing your swing against a live pitcher with variation in the types and locations of each pitch. It tests not only your fundamentals, but your ability to react to different, unexpected situations. When done in production, dynamic analysis is like perfecting your swing at the bottom of the 9th with the bases loaded. Did I mention that the score is tied with 2 outs? The stakes are high.
Now, let’s compare and contrast the two different styles from a technical perspective.
Static code analysis is a method of debugging done by examining an application’s source code before a program is run. This is usually done by analyzing the code against a given set of rules or coding standards.
These often address code vulnerabilities, code smells and adherence to commonly accepted coding standards. These include common developer errors which are often found by “Code Peer Reviews”.
Static code analysis is usually incorporated at any stage after the “Code Development” phase and before “Unit/Component/Integration” testing phases. In some cases, CI/CD pipelines incorporate Static analysis reports as a quality gate for code promotion.
Among other benefits, the ability to identify weaknesses in the code and to adhere to strict development standards help reduce potential production issues. These also provide “Test Coverage” reports that describe the degree to which the code has been exercised.
In real life, what works for “Joe” doesn’t work for “Jane”. Static code analysis treats both the same since it cannot see the data.
Consider the following pseudo code:
function getFullName(firstName) {
if (firstName == “Joe”)
return “Joe Smith”if (firstName == “Jane”)
return “Dave” // This is incorrect business logic
if (firstName != “Joe or Jane”)
return “Joey”
}In the above example, static code analysis provides no understanding of developer intent. A user expecting “Jane’s” full name as “Jane Doe” gets “Dave”. Any other name returns “Joey”. Any downstream application expecting a valid user would now face runtime errors or exceptions.
Issues like these could easily pass “Static Code analysis rules,” JUnits, even “Code coverage” reports. Production is the “Wild Wild West” and often contains a plethora of business flavors. “Production scenarios” don’t adhere to any given set of rules.
Finally, automated static code coverage tools often provide a false sense of security that everything is being validated. The truth is that the reports are only as good as the underlying rules that govern them.
Dynamic code analysis is the method of debugging by examining an application during or after a program is run. Since the source code can be run with a variety of different inputs, there isn’t a given set of rules that can cover this style.
These address runtime vulnerabilities that occur due to variations in business context. For example, the code snippet from above would be flagged by dynamic code analysis. Tools such as OverOps take this a few steps further.
These can be used in multiple places.
In production, dynamic code analysis helps provide visibility to application issues, reducing MTTI for production incidents. Overops goes even deeper – determining the exact offending line of source code with variable values.
If the code doesn’t run, it doesn’t get analyzed. In addition, dynamic code analysis cannot perform the function of static code analysis tools, so it’s best used in conjunction with them.
Just like practicing your swing against both a machine and a live pitcher, static and dynamic analysis go hand-in-hand. Static code analysis often finds issues in unexercised code that dynamic code analysis can’t. At the same time, dynamic code analysis covers production scenarios that static analysis doesn’t.
Harness enables you to bring these two approaches together to ensure your code is truly production-ready. By feeding data directly into popular static analysis tools, users are able to enhance their existing quality gates with insight into runtime errors.
To see this integration and our other plugins in action, sign-up for a free Harness trial.
Sign up for our free plan, start building and deploying with Harness, take your software delivery to the next level.
Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.
.svg){kind=small}
Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.
.png)
