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…

With Teamscale 4.0, we finally released pre-commit analysis, a feature that we and many of our customers have been looking forward to for quite some time. In this post, I will give you a brief overview of the feature and explain, why we are so excited about it.

We are happy to host the first ABAP Code Retreat (ACR) in the Munich area. It will take place on Saturday, February 24th 2018. Registration is open now—to register, please visit the registration page.

This event is a great opportunity to experience a Code Retreat in ABAP and to expand your ABAP skills. Spend the day with ABAP colleagues, connect with your peers, learn from each other, share experiences and be inspired by the great community. Just bring your own laptop. We provide you with an ABAP stack and access to the system for the event. In addition, we offer lunch, snacks and soft drinks for free!

We are happy to host the first ABAP Code Retreat (ACR) in the Munich area. It will take place on Saturday, February 24th 2018. Registration is open now—to register, please visit the registration page.

This event is a great opportunity to experience a Code Retreat in ABAP and to expand your ABAP skills. Spend the day with ABAP colleagues, connect with your peers, learn from each other, share experiences and be inspired by the great community. Just bring your own laptop. We provide you with an ABAP stack and access to the system for the event. In addition, we offer lunch, snacks and soft drinks for free!

When giving presentations or demos about Teamscale, we often get asked whether we use Teamscale for developing Teamscale. The answer is a clear »Yes!«. In this blog post, I’d like to shed some light on why and how we use Teamscale at CQSE.

Regardless of whether it is called eat your own dogfood or drink your own champagne, we are convinced that using your own product is essential for making your product great. Consequently, dogfooding is an integral part of the Teamscale development process. Not only do we believe that Teamscale helps us to write better code, we also think that it is very insightful to get an unfiltered impression of the end user experience of our tooling on a daily basis.

In particular, we see three benefits. First of all, Teamscale…

Redundant source code fragments—code clones— are a major indication of low-quality code. Code clones require you to propagate your code changes to multiple locations always risking to overlook individual locations.

This does not only increase the time needed to change the code but also leads to incomplete and costly bugfixes. Because code clones are one of the top-rated bad smells, Teamscale has a sophisticated algorithm to locate and inform about redundant code fragments.

However, when discussing code clones with Teamscale users, we often hear that »this is not a clone because there is no senseful way to eliminate the redundancy« I wrote this post to dispel this misunderstanding.

Over the recent years, version control systems have started to consolidate.

While there were lots of proprietary systems in the past, the world now seems to agree that distributed systems such as Git are the way to go in most cases. At CQSE, we switched our own development infrastructure from SVN to Git in 2016.

In this post, I will outline some important lessons I learned from migrating several code bases from proprietary solutions to Git over the last years.

Over the years, we have set up Teamscale for many customers. During these times, we learned a lot about how to set it up, which other tools are useful and how to maintain a Teamscale instance over time. We worked with small as well as with large teams and infrastructure ranging from the PC under some guy’s desk to a multi-server installation in the cloud.

Throughout all of these ventures, we found some best practices that I’d like to share with you.

In my last blog post I outlined the obstacles we had to master when moving from Subversion to Git. Since then more than one year has passed and several of the assumptions we have once made no longer hold. This post describes what changes we had to make in our development process and build & deployment infrastructure due to migrating to Git and which improvements we gained.

Our mission at CQSE is to help customers improve the quality of their code. Our tool Teamscale checks source code and reports issues such as logical flaws, copy&paste programming and possible performance bottlenecks.

However there is one aspect of code quality that we did not address so far: code security. Code is secure if it can not be used by an attacker to perform unintended, dangerous actions on the host system.

In this post, I will explain how new analyses in Teamscale can efficiently detect vulnerabilities for such attacks and report them to developers.