Static Analysis for the Build Machine?
Editorial Note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site. While you’re over there, download a trial of NDepend if you want to see some quantification of the tech debt in your codebase.
I remember my earliest experiences with static analysis. Probably a decade ago, I started to read about it during grad school and to poke around with it at work. Immediately, I knew I had discovered a powerful advantage for programmers. These tools automated knowledge.
While I felt happy to share the knowledge with coworkers, their lack of interest didn’t disappoint me. After all, it felt as though I had some sort of trade secret. If those around me chose not to take advantage, I would shine by comparison. (I have since, I’d like to think, matured a bit.) Static analysis became my private competitive advantage — Sabermetrics for programmers.
So as you can imagine, running it on the build machine would not have occurred to me. And that assumes a sophisticated enough setup that doing so made sense (not really the case back then). Static analysis was my ace in the hole for writing good code — a personal choice and technique.
Fast forward a decade. I have now grown up, worked with many more teams, and played many more roles. And, of course, the technological landscape has changed. All of that combined to cause a complete reversal of my opinion. Static analysis and its advantages matter far too much not to use it on the build machine. Today, I’d like to expand on that a bit.
What Does It Mean to Have Static Analysis on the Build Machine?
First point of expansion should be to mention what this means. In the general sense, this means that the machine responsible for assembling your code into something deployable executes static analysis on said code. Back when I first discovered static analysis, this would have meant pulling the code from source on that machine, running the analysis and building it. These days, hopefully your build involves more automation than this.
To get a bit more detailed, a commit may trigger your build machine to kick off a build. That could just mean compiling your code and packing it into a deployable format. But shops commonly do other things, such as execute automated unit tests and check on code coverage. And you can add static analysis to the mix.
You can certainly get creative with how you do this. But two common (and not mutually exclusive) approaches include having the build generate a code health report and failing the build on egregious violations.