Applied Automation TeamCity and NDepend
This guest blog post is from Wes McClure, Software Consultant and Founder of Full City Tech Co., a JetBrains Training and Consulting Partner.
Inspecting code can provide valuable insight into improving the design of a system. Inspection tools are most valuable when they’re integrated with the environments that developers use to create software. They can provide instant feedback to improve, on the fly.
Inspection is also valuable as an analysis tool after the fact. One barrier to analysis is the time it takes to setup and inspect a code base. This process is ripe for automation so time can be spent analyzing results, not gathering them.
But, blindly automating anything is as reckless as avoiding automation altogether.
Often, when discussing inspections, I find individuals wanting to inspect code bases every time a change is made to the system.
I’ll inquire how often do you perform this analysis currently and what do you do with the information? Often, I find there’s no methodical approach and sometimes inspection isn’t even a part of an existing process. It’s just something that someone said was a good idea.
Whatever the case, by stepping back and discussing how often the information is used and what it’s used for, we can begin to understand the value of automating inspections.
By challenging ourselves to understand why the information is valuable, we can determine the appropriate level of automation to improve.
Most teams are busy enough, they’ll be lucky to look at inspection results once a week. And, if they have to manually generate it, it’s much less likely they’ll even get around to it.
But, if inspection reports are automatically available on a weekly basis, they could invest more time in analyzing the results. And in turn, invest in acting on the results.
NDepend is a tool to inspect a .NET code base and provide actionable metrics to improve.
TeamCity is a platform to automate development processes, gather results and act upon them.
Let’s walk through the basis for automating inspections with NDepend and TeamCity.
First, we should outline the process.
NDepend is used to inspect a code base. This requires checking out the code, compiling it and then analyzing the results with NDepend.
Then, teams analyze the results for ways to improve.
And over time, they apply this insight to incrementally improve.
Eliminate the unnecessary
After outlining the process, it’s important to eliminate vestigial components. In the case of inspections, this is a matter of making a conscientious decision about what inspections are meaningful and what aren’t. Don’t just take everything out of the box. And, spend some time with NDepend to craft your own custom inspections.
Next, it’s important to establish objectives. NDepend comes with the concept of rules. Reducing rule violations can improve the quality of a code base. For example, NDepend comes out of the box with rules that help detect breaking changes to software interfaces. It also provides rules to detect dead code which can hamper the longevity of software. Deciding on a set of rules to enforce may serve as a worthwhile objective.
Let’s say we want to reduce dead code in a system. Every system contains some amount of dead code. Some of it can be detected automatically. Measuring the current level of dead code in a system and setting goals to reduce it serves as a progress indicator.
What if your system is comprised of ten percent dead code? What would it be worth the get that to five percent? What about one percent?
Make a decision
Everything above becomes the basis with which one decides to automate, or not automate, inspections of dead code or any other aspect of a system.
I always recommend a margin of two or three times the potential cost. That way you have room to absorb the unknown.
There’s no better way to describe automating it than to show you:
Over time, use the information you capture in TeamCity from the output of NDepend to see if efforts prove worthwhile.
Not everything is so easily quantifiable. Nonetheless, you can start to see how you can apply a methodical process focused on value to scientifically improve your development process.
The original post was published September 11th, 2014 on www.wesmcclure.com.
Subscribe to Blog updates
Simple Fork-Join Framework With Matrix Builds
Matrix build in TeamCity executes the same set of steps on different combinations of input parameters, producing a matrix with the result of every execution, while using the Fork-Join pattern under the hood. Let’s see how this works.
How To Choose a CI/CD Tool: A Framework
In this blog post, we offer general guidelines for selecting an appropriate CI/CD solution and delve into how TeamCity fits into this framework.
Increase Your Productivity With TeamCity Documentation Examples for the Kotlin DSL
Take advantage of extensive Kotlin DSL documentation for TeamCity - now with examples! Read more about how it might increase your productivity in this blog post.