Last article in our series on creating custom metrics.
We will address different costs regarding the customization of metrics, generally poorly identified or completely ignored in a project of selection of a code analysis tool.
We will conclude by summarizing all the different questions to ask to a customer in order to determine if creating custom metrics is really a criterion for choosing such a tool.
Continue reading
Third article in our series on creating custom metrics, and why the ability to define your own metrics in a code analysis tool is not the important factor that everyone believes it is.
We saw in the first article that the most simple metrics were not the most numerous and in the second post in this series, that the most interesting and important rules were also the more complex to implement, sometimes (or often) impossible.
In this post, we will address the issue of customization in terms of application technology, before a final article will summarize and identify all the right questions. Continue reading
Is there any interest in creating its own metrics in a code analysis tool? What benefits can we expect? What disadvantages? What obstacles are we going to meet?
It always strikes me to see that these issues are mostly ignored when choosing a tool. Most of the times, the question is to know what is the ease or the level of difficulty to customize the software and create his own rules rather than wondering if it is really needed.
The objective of this series of articles is therefore to clarify these questions and help you to choose the right criteria if you want to acquire a code analysis tool. If you are a quality consultant and must assist a client for such a choice, you can discuss these issues with him to help him in his selection. Continue reading
A quality consultant asks me if it is “Possible to create your own metrics with Sonar?” and “Is it easy to introduce new rules?”.
I know he is working for a customer who wants to choose a code analysis tool. And this is the typical criteria that you will systematically found in the specifications that are elaborated when it comes to choosing such a tool.
It has become a universally accepted rule, even to the point that some software vendors have made of this a selling point and include in their pre-sales demos the creation of a new rule. This is not critical but people like it. Can you imagine a car salesman opening the hood of a running vehicle to adjust the carburator or to add fuel? It would be spectacular, but is it really useful? Continue reading
Another milestone for Qualilogy : 20 000 unique visitors in less than 18 months.
If you do remeber, this blog has reached 10 000 visits in 1 year.
This same number of visitors has been added in less than 172 days (last thursday May 16). Or to say it differently, Qualilogy has doubled in the last six months. Continue reading
This series of articles on installing SonarQube will end with this post. Let’s remember what were the objectives:
You are a pro in the Mainframe Cobol or SAP worlds, or a quality consultant, you act as as stakeholder or an interface between users and project teams, you are a project manager in charge of managing outsourcers for your IT department: this series showed you how to install SonarQube on your PC (a simple laptop in my case) in order to easily and regularly analyze any delivery of code or a new version of an application.
After installing Jenkins, we will now see how to interface it with our SonarQube environment.
If you have not been following along this series about creating an environment of code analysis with SonarQube, here are the items we need today:
You can also have a look at the documentation about configuring the SonarQube Jenkins Plugin, on the SonarSource website.
In this series of posts on the installation and configuration of SonarQube, we have seen how to realise a first analysis of code with the SonarQube Runner.
Today we will see how to install and configure Jenkins that we will use (later) to manage all our analysis.
This is also an opportunity to detail the resolution of some problems specific to our environment, and incidentally to see how to detect these problems with the Tomcat server, which we have installed previously.
We have previously installed the SonarQube portal with Tomcat, and the SonarQube Runner, which will enable us to achieve our first analysis today.
In the installation folder of the SonarQube Runner, we cand find three directories:
Before configuring it, let‘s pause a moment to think about the organization of our analysis environment.
The SonarQube Runner allows us to perform source code analyzes without using tools such as Ant or Maven.
These toos are well known from J2EE (or any other new technology) development teams, but let’s remember that our objective in this serie about the installation of SonarQube, and more generally in our blog, is to allow anyone to perform code quality and applications analyzes, without requiring any knowledge of these new technologies. Continue reading