Thomas Kinnen

… ist Berater der CQSE GmbH für kontinuierliches Qualitäts-Controlling. Er studierte Informatik an der Technischen Universität München, wo er mit einem Master of Science abschloss.

  • +49 space::176 space::10155275
  • @nihathrael

Blog Posts

Over the past years we’ve seen customers loading hundreds of projects into single Teamscale installations, used by many users. And while Teamscale can handle the analysis of dozens of projects on a single machine, this often means running the hardware at maximum capacity, even on very large machines. With the release of version 4.1, Teamscale is now cloud ready. To keep up with increasing numbers of users and projects handled by single Teamscale instances, we’ve been hard at work on a horizontally scalable deployment for Teamscale. It is now possible to deploy Teamscale onto many machines, making use of extra resources to handle larger work loads.

In this blog post, I will present an architectural overview of how Teamscale can be deployed for such a setup.


On our mission to support development teams improving their products’ software quality, we strive to support their development process the best we can.

To do this, Teamscale has always analyzed every commit on the mainline in the repository for potential problems. However, recently many teams (including ourselves) have switched from a single development line to a branched based development approach (e.g., git flow, merge requests or manual Subversion/Team Foundation Server branches). In these models, the actual development usually happens on one or multiple branches and the mainline consists (mostly) of merge commits. Because only the final merge commit was analyzed after the feature’s development had ended, we could no longer give the developer near real-time feedback on their work.

To support this style of development we made branches a first class citizen in Teamscale 3.0. It can now analyze every commit on every branch, restoring our idea of rapid feedback for the branch-based model.

In this post, I will present how branch support looks like in Teamscale and how developers can work with it to create the best code possible.


A year ago we released the first version of our web-based architecture editor. It was lacking one major feature: saving architectures directly into Teamscale from the browser. This will change with the upcoming release 2.1:

In this post I will outline how to create a new architecture for an existing system, demonstrating the usage and usefulness of real-time architecture analysis.


Have you ever run into a »new« or »trending« programming language (Rust, nim, Kotlin, etc.), promoting all sorts of great »new« abstraction mechanisms (traits, mixins, multiple-inheritance, monads, lambdas, macros, you name it), thinking: »I could finally get rid of all this copy-pasted or boilerplate code we have in our codebase!«?

I discussed whether newer/trendier languages will lead to less copy-pasted code (or even better code quality in general) with a few colleagues over a few beers recently. Based on our experience as consultants for software quality and Teamscale developers, we quickly came to the conclusion: No, they will not.

Let me explain and give a few examples.


In this blog post I will show you how to start with IntelliJ IDEA plugin development. Since there is not a lot of documentation about plugin development for IntelliJ IDEA, I’ll be explaining how to create a simple plugin and execute code after a project was opened using the StartupActivity class.


Teamscale is our tool for continuous software quality control. It provides feedback about quality problems in near real-time, allowing you to keep your software free of technical debt.

Today we are proud to announce our public demo, allowing you to try and explore Teamscale easily.

To get started, go to our Teamscale Demo registration page and register a user for the live demo. You will get an e-mail containing your new password and a login link. Follow the link to login and explore Teamscale.