Over the last few years, Docker has largely been adopted to ease the deployment of applications.

One of the key benefits is bundling all required dependencies of an application in a single image that can be used right away without a huge installation and configuration overhead. Hence, we are using Docker for running our own Teamscale instances, as well as for Teamscale instances at the customer site.

Docker containers are also neat when testing and reviewing new features before they are merged back into master.

Especially on a local developer machine it is beneficial that the Docker image is small, because you don’t want to waste your SSD space with gigabytes of Docker image data.

Over the last years the Teamscale Docker image became quite large,…

A code quality control process must not be solely based on automated tools, rather it should combine tool-based analysis with a certain amount of human interaction.

There are endless variations of how a code quality control process can be implemented.

In this blog-post I’d like to give a few insights on how regular code assessments, named here monthly assessments, can lead to a feedback loop that improves the code quality control process.

Quality Control is one of the major services we do at CQSE. The aim of quality control is to stay (almost) clean of quality deficits or to achieve a continuous improvement regarding quality.

In most cases we focus on the quality of source code. To keep it simple, I will stick to code quality throughout this post. I will focus on two aspects of this process: Quality tasks and how these relate to quality goals.

Die CQSE GmbH ist im Finale um den Deutschen Gründerpreis. Die Jury ist beeindruckt von der rasanten Entwicklung des Unternehmens.

Der Analysesoftware-Hersteller CQSE GmbH ist für den renommierten Deutschen Gründerpreis nominiert. Das Garchinger Unternehmen zählt zu den Top-3-Finalisten in der Kategorie »Aufsteiger«. Damit bewertet die Jury die CQSE GmbH als eine der erfolgreichsten und vielversprechendsten Existenzgründungen der vergangenen Jahre in Deutschland.

Software is made of code. Well, yes, but not exclusively. Software engineering involves working with many other artifacts, such as models, architectures, tickets, build scripts, … and tests.

The goal of Teamscale is to provide meaningful and useful information about all aspects of software engineering. This is what we call »Software Intelligence«.

Consequently, in addition to providing profound insights into code quality, Teamscale performs many other sophisticated analyses, including architecture conformance analysis, analysis of issue tracker data, team evolution analysis, code ownership analysis, or data taint security analysis.

As developers, we can all relate to that sense of accomplishment when a feature is finally done.

You’ve spent a lot of time planning the implementation, ensuring that all cases and any imaginable scenarios are handled, and that the feature functions as intended. You’ve checked your code into the shared code repository and now you’re done! Or are you?

»Is my feature done?« is actually a vague question with no definitive or unique answer. And in order to answer this question, each

team needs to define their own Definition of Done (DoD). The Definition of Done is a checklist of activities or conditions that need to be completed before a software product or a development task is considered as done. Examples for these activities are: writing code, coding…

I have always been a fan of architecture diagrams: I simply like the elaborate drawings that show how the complex whole is divided into parts and how those parts are connected.

These blueprints are an essential foundation for any discussions and it is expected that they match the reality as closely as possible.

»Big design up front« has proven to be impractical in the software domain.

For any non-trivial project, the domain complexity is usually so high that completing the design before starting the implementation is simply inefficient. As a counter-movement, some proponents of »agile« software development go as far as proposing no upfront design and no documentation at all. I find both approaches alarming and impractical. In this blog post, I will try…

After several technical blog posts I think it’s time for something different: I really enjoyed yesterday’s work day

Why?

Because of the freedom I have to manage and arrange my work time at CQSE as I like. I’ll briefly recap the whole work day in this blog post, explaining to you what this exactly means.

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.