G. Ann Campbell wrote:These are great questions, Burk. I believe Patroklos did mean a second book for people who wat to extend SonarQube. As to the target of the current book, we had many discussions on that - both between the two of us and with the Manning staff.
We really hoped that this book would be accessible to everyone on the development team (coders, testers, project mgmt) as well as to some lower levels of management. I'm really hoping a few VP's and maybe even C-level folks read at least the first chapter to get the jist and either push the ideas down or use it to understand what's being pushed up.
Patroklos Papapetrou wrote:Hi Burk
Ann covered me already. What I meant is to write a book for developers that want to extend SonarQube, write plugins, use its web services etc.
SonarQube in action, actually targets all kind of development team members : Developers, Testers, Team Leaders, Technical and non-technical managers, architects, Quality assurance guys or whoever interacts with one or another way with the project's quality.
Patroklos Papapetrou wrote:There is a whole chapter in SonarQube in action that guides developers step-by-step on how to create a SonarQube plugin from the scratch.
Another good reference is SonarSource's online documentation : http://docs.codehaus.org/display/SONAR/Extension+Guide
And finally what I prefer to do ( after reading SonarQube in Action last chapter ) fork some existing plugins and see how they do it
I took a quick look at the online docs and it looks like there's a lot of Extension points that a plugin could use. Are they all explained in "SonaQube in Action"?
G. Ann Campbell wrote:Burk,
There are some plugins that would probably appeal to PM's such as the Green Pepper plugin, plus the Jira (and the like) integration. But what I really intended/meant/hoped was that PM's would see software quality as a deliverable for each release. Just like the monitor the bug list & the features list & the burn down, IMO they should also monitor project quality. Keeping quality high means reducing the likelyhood of introducing new bugs and also means you'll be able to maintain your pace of development long-term.
I've been on projects before that started out fast - delivering lots of features very quickly - but eventually ground to a halt under the weight of the technical debt. A good PM should IMO help keep that from happening by making sure that the foundations of good software quality are laid and maintained, and allocate time in the schedule to make up any lost ground in that area.
Patroklos Papapetrou wrote:No unfortunately we had time and space (pages) only for some of them. But I'm pretty sure that you'll get the general idea of how SonarQube's plugin system works and of course it will get you started faster.