| Re: [mdmbl-dev] Sonar integration successful |
|
At the moment all projects are analysed based on the follwing default Eclipse SonarQube settings: Quality Gate: “SonarQube way” (https://sonar.eclipse.org/quality_gates#show/1) Quality Profile: “Sonar way with Findbugs” (https://sonar.eclipse.org/profiles) Currently there is no option to change neither gate nor profile, but the lacking rights might by a thing to discuss with the Eclipse guys. They really helped us the last days (THANKS for that!) to
get Sonar working and still are. But for the moment we’re happy for the successful integration.
Upcoming things in that topic are questions about the technical dept as mentioned by Ralph, priorisation, usage focus, development process integration (e.g. to have Sonar report back to Gerrit and
set verified +1/-1 and adding by that a quality gate to the code on a per changeset basis, what leades to instant learning not only about the functional side of the code (that at the very end results in successfully build and tested code delivered by Jenkins
and triggered by Gerrit), but also about how it’s done, e.g. both language and design tweaks and pitfalls, best practices, code coverage, etc. And the changeset focused view allows you to get a first automagically created opinion about your contribution and
- best case - good input … ups, I must have got carried away). This discussion might have its place (at least a part of it) in the Quality Committee as well as among us developers, preferably both independently and together. But at least I have no knowledge
of the former beeing happened already. Comments about that would be appreciated and helpful. The latter will be discussed in one of our next developer meetings. But to start with some kind of reduction mechanism for the 1478 Sonar issues has its point. To go repository by repository might by practical in terms of calculatable dependency issues. To have a
filter on just the Major ones (as there are 0 Blocker and only 4 Critical) is not reduced enough, still 1070. So maybe a combination of both or something different (in addition). To change the Profile as suggested would also help to stay focused, but has one disadvantage: we need time to either build a new profile or delete rules from the default one, choosing rules that
stay active that reduce the mere number of issues (to go “sloppy”) while keeping the quality-cost-/quality-time-pair in balance, but only in case we trust all the rules to apply in general and in particular to our code scenario and we and our code would benefit
from them. And in the end (after some iterations within the hopefully next project phases with that team ;-)) they should and hopefully would be part of our rule set again. But in case we are skeptical regarding general appliance, particular appliance for
API, implementation, UI and so forth (are we?), we end up at least speed read a good bunch of the 513 rules of the current profile (namely the applied ones (what about arising issues in the future no thought about?)) and – under optimal circumstances – discuss
and decide on each of them. We would definitely learn a lot and also the code would greatly benefit from it. Considering time and budget I think it would be too expensive at least in that project cycle. But one could – to take a piece of this idea – identify
rules by the numbers of thereby created issues and have a closer look on them. But I would prefer a filter instead of a changed profile nevertheless. That’s all for now. As soon as we developers proceed with this topic and got some first ideas we can bring them up. Regards Alex ----------------------------------------------------------------- Alexander Nehmer Senior Software Engineer science + computing ag Phone: +49 (0) 7071 9457-633 Mobile: +49 (0) 171 550 86 94 E-Mail: alexander.nehmer@xxxxxxxx Hagellocher Weg 73 D-72070 Tuebingen Website: de.atos.net/sc
Von: mdmbl-dev-bounces@xxxxxxxxxxx [mailto:mdmbl-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Stefan.Ebeling@xxxxxx … which Sonar configuration is in use? Who decided the severity of the issues? Should (and can) we fine tune this configuration? E.g. start with a „sloppy“ one and then raise
the level to „fussy“. Best Regards Stefan Ebeling BMW Group Group IT –
Versuchs- und Messdaten-Management (FG-453) Bremer Straße 6 80807 München Postanschrift: 80788 München Tel.: +49 89 382 75 756 Mail: stefan.ebeling@xxxxxx -------------------------------------------------------------------- Von:
mdmbl-dev-bounces@xxxxxxxxxxx [mailto:mdmbl-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Nehmer, Alexander Hi Ralph, yes, there are plans: we already spoke about starting to fix the important issues within the next sprint, but there are no definite Sonar tickets yet we plan to do. I think we’ll start this in the
next days. Regards Alex Von:
mdmbl-dev-bounces@xxxxxxxxxxx [mailto:mdmbl-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Ralph Mueller - Eclipse Foundation I agree to Stefan's email. Well done. Any plans in the project to deal with the technical debts? Ralph Mueller +49 177 449 0460
|
