G. Ann Campbell - SonarQube in Action

For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact

2014 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps.

Recognizing the importance of preserving what has been written, it is Mannings policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine.

Manning Publications Co.20 Baldwin RoadPO Box 261Shelter Island, NY 11964

Development editor: Susanna KlineCopyeditor: Tiffany TaylorProofreader: Toma MulliganTypesetter: Dottie MarsicoCover designer: Marija Tudor

ISBN 9781617290954

Printed in the United States of America

1 2 3 4 5 6 7 8 9 10 EBM 18 17 16 15 14 13

To the software architects, programmers, testers, project managers, executives, and end users of every piece of software ever written. We hope this book will make your lives easier.

The software industry is still a young industry in which software quality means for many people pain, cost, constraint, nice to have, one-shot effort, or external reviews. Fortunately, with the Agile movement, the industry has started to realize during the last decade that software quality also means fun, built-in, rewarding, and higher productivity. Ann Campbell and Patroklos Papapetrou belong to the latter group, and they strongly believe that software quality should be a daily concern shared by all stakeholders in the industry for long-term success.

Software quality is divided into external and internal quality. External quality looks at how well the software fulfills its functional requirements: in other words, whether youre building the right software. Internal quality looks at how well the software is designed/implemented to constantly welcome new changes: in other words, whether youre building the software right. Industry statistics show that on average, 80% of the cost of software is spent on maintenance; there is considerable variability depending on internal quality. This makes internal quality a key component for the future cost of software.

This is the reason why managing code quality of applications has become a major concern for any company that builds or is involved in building software. Traditional approaches to managing code quality propose to test code from time to time, mainly at the end of a development phase. In the best case, this approach leads to delays and re-work; in the worse case, it leads to the shipment of poor-quality, expensive-to-maintain software. There is therefore an urgent need for a new approach: one that clearly gives ownership of code quality back to the development team; one that emphasizes quality throughout the development phase and has a shorter feedback loop to ensure rapid resolution of quality problems; in short, a model that builds in quality from the start, rather than considering it after the fact.

This is the mission we have set ourselves at SonarSource: to provide tooling for support of this new approach called Continuous Inspection. This is what we believe we have achieved with SonarQube, the open source platform to continuously manage technical debt. SonarQube has a large ecosystem, is widely adopted, and has a very large community. Ann and Patroklos are part of this community and among the most active members, contributing not only by their feedback but also by expanding the ecosystem. When they approached me with the idea of writing a book, I was thrilled, because this is clearly something that is missing in the SonarQube ecosystem. Having Ann and Patroklos writing it also meant it would have some great insight from the community and, more important, that it would contain the end-user perspective on the solution.

This book will be your companion in your journey with SonarQube. It will take you from why you should use SonarQube to installation, configuration, administration, and utilization of services, up to extending the platform. You can use it either by reading through from A to Z or as a support reference for information about a specific topic.

But that isnt all! Ann and Patroklos also discuss the process surrounding the tool, challenge existing and missing functionality, and provide numerous tips for using SonarQube, all based on their own experience. Whatever your level of familiarity with the product, youll learn from this book. This is what, in my opinion, makes this book a unique source of information for a successful implementation.

Enjoy!

O LIVIER G AUDIN

CEO AND COFOUNDER

S ONAR S OURCE

Would you like to help me write a book about Sonar? My reaction was immediate: Yes!

I knew Patroklos Papapetrou from the Sonar mailing list, and I was aware that he was pitching Sonar in Action (now SonarQube in Action, to match the technologys new name) to Manning. What I didnt know was that he wanted a coauthor. Because I was a native English speaker and active (and helpful) on the list, he thought of me. I had only been a member of the list for about six months, but Id been aware of Sonar since late 2008 when my boss came across a mention of Sonar and asked me to evaluate it.

I was coding in Java at the time, but I had started my programming career with Perl and C. Lint was your friend, and bugs were found the hard wayby the users. So I found Sonar intriguing. It promised to scan each line of code and point out all kinds of things that were wrong or could go wrong. But to use it, you had to be building with Maven. Unfortunately, we were in an Ant-build shop. Sonar was off the table.

Fast-forward to early 2010. Sonar was approximately three years old, but already it was gaining broad acceptance among community and enterprise users and being downloaded more than 2,000 times a month. Patroklos had found the Sonar website while researching software quality tools, and it was a classic boy-meets-software story. (Cue the sappy music.) It didnt take long before he was in love and Sonar was one of his favorite tools.

Meanwhile, I had begun moving our Ant builds to Jenkins (it was still called Hudson then), and I stumbled across the Sonar plugin for Hudson. It works differently now, but at the time, it performed a shallow Maven-ization of a non-Maven project and ran an analysis. Hmmm. Maybe Sonar was back on the table.

I installed Sonar and the plugin on my localhost and ran an analysis. When I poked around in the results, I didnt understand everything I was seeing, but I knew I liked the way it presented issues in the context of the offending code. And because Sonar had a web-based front end, instead of having to send quality reports to people, I could send the