Over a million developers have joined DZone.

It Wasn't Me: Baselining in Teamscale

DZone's Guide to

It Wasn't Me: Baselining in Teamscale

· Performance Zone
Free Resource

Discover 50 of the latest mobile performance statistics with the Ultimate Guide to Digital Experience Monitoring, brought to you in partnership with Catchpoint.

[This article was written by Dr. Nils Göde]

Almost every long-living software system has accumulated an abundance of quality deficits over time. It’s not only impossible to remove all findings, I also do not recommend to do that. You may very well argue to not remove any legacy finding by saying »It has worked all the time« or »It wasn’t me who introduced the problem«. But then—on the other hand—you should make sure that you don’t introduce any new problems. To check this, you need a tool that can reliably differentiate between legacy findings and findings that have been recently introduced. This has to work also if directories of files are renamed, code is moved between files and findings change their appearance in the code. Making the distinction between legacy and recent findings is one of the many strengths of Teamscale.

Teamscale has a sophisticated method of tracking findings even if code changes or moves. This means Teamscale has the complete history of every single finding and knows when it has been introduced. Therefore, Teamscale can tell you reliably for every individual finding whether it is a legacy finding or a finding that has been recently introduced.


You, as a user of Teamscale, can define which findings are considered legacy findings by setting one or more »baselines«. Each baseline specifies a certain point in time or a revision in your version control system. Baselines can, for example, be set to releases or important milestones during development.

Configuring Baselines

Once you have configured baselines, you can select a baseline in the Findings perspective.

Selecting Baseline

The Findings perspective will then show only those findings that have been introduced after the selected baseline. This way, you can easily find out which findings have been recently introduced and should be addressed.

Findings Since Baseline

Needless to say that baselining works also with the IDE plugin. That means you can also configure your IDE to show only those findings from Teamscale that have been introduced after a given baseline. In summary, baselines are a powerful feature of Teamscale that allows you to concentrate on recent findings and don’t waste any effort cleaning up code that has worked all the time and fixing legacy problems that you have not introduced.

Is your APM strategy broken? This ebook explores the latest in Gartner research to help you learn how to close the end-user experience gap in APM, brought to you in partnership with Catchpoint.


Published at DZone with permission of Nils Göde, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}