Unser Team untersucht in unserem Projekt verschiedene Optionen für die statische Analyse und hat gemischte Meinungen darüber, ob unser Continuous Integration-Build aufgrund von Warnungen durch statische Analysen scheitern soll.
Das Argument gegen das Fehlschlagen des Builds besteht darin, dass es oft Ausnahmen von den Regeln gibt und der Versuch, sie zu umgehen, nur um den Build erfolgreich zu machen, reduziert die Produktivität. Ein besserer Ansatz wäre es, Berichte mit dem Build zu erstellen und den Entwicklern regelmäßig Zeit zu widmen, um die gemeldeten Probleme zu beheben.
Das Gegenargument ist, dass die technischen Schulden leicht aufgebaut werden können, wenn die Fehler nicht sofort behoben werden. Wenn die Erstellung fehlschlägt, wenn ein potenzieller Fehler eingeführt wird, wird die Zeit verringert, die benötigt wird, um den Fehler zu beheben.
Was sind deine Gedanken?
Ich persönlich würde eher sehen, dass der Build fehlschlägt. Während einige Warnungen falsch positive sind, können Warnungen mithilfe von SuppressMessageAttribute mit Justification ausgeschlossen werden. Wenn Sie dies tun, sind Sie sicher, dass jede Warnung von den Entwicklern ausgewertet wird und nichts einfach durchgeht.
Es ist wahrscheinlich eine gute Idee, den Build zu scheitern, aber das muss keine absolute Schwarz-Weiß-Entscheidung sein.
Hudson lässt Sie einen Build abbrechen, wenn ein bestimmter Schwellenwert für neue statische Analysefehler überschritten wird. Sie können also sagen "Markieren Sie den Build als instabil, wenn 1 neuer Fehler eingeführt wird; markieren Sie den Build als fehlgeschlagen, wenn 5 neue Fehler eingeführt werden".
Dies ist etwas, das in die verschiedenen Analyse-Plugins integriert ist, die für Hudson verfügbar sind.
Ich mache normalerweise das Build-Scheitern bei statischen Analysen Fehler (nicht nur das CI-Build, sondern auch das, das auf dem Developer-Rechner vor dem Commit läuft und ich verwende Tools, die in der IDE enthalten sein können) .
Wenn Sie das nicht tun, ist meine Erfahrung, dass Fehler nicht behoben werden und tatsächlich nie werden, denn wenn Sie Fehler als kosmetisch betrachten (oder Sie würden das Commit nicht erlauben, oder?), wird es immer geben etwas Wichtigeres zu tun. Wenn es eine berechtigte Ausnahme gibt, erlauben die meisten Tools, Codeabschnitte auszuschließen (mit Dingen wie einem benutzerdefinierten Kommentar oder einem Ausschlussfilter).
Wenn Sie die statische Analyse verwenden möchten, tun Sie es richtig, beheben Sie das Problem, wenn es auftritt, lassen Sie einen Fehler nicht weiter in das System übertragen. Ein Prozess, der dies ermöglicht ist falsch :
Machen wir Toast im amerikanischen Stil: Sie brennen, ich kratze. --W. Edwards Deming.
Tough Call, ohne eine gute globale Antwort. Ich würde gerne den beiden vorherigen Postings zustimmen und ja sagen, aber mein zweites Gesetz der statischen Analyse sagt, dass sich Defekte in Teilen der Organisation versammeln werden, in denen der Softwareentwicklungsprozess am schlimmsten durchbrochen wird. Eine logische Folge ist, dass Ingenieure, die gezwungen sind, ihren Code in Eile zu ändern, um die Warnungen wegzulassen, diejenigen sind, die am wahrscheinlichsten neue Probleme einführen werden, wenn sie dies tun; Ich habe deprimierend viele solcher Käfer gesehen. Ich denke, es ist eine bessere Software-Entwicklung, um die falsch-positive Markierung außerhalb des Codes zu machen, wie beispielsweise in Coverity und Klocwork, und darauf basiert Ihre Durchsetzung.
Es versteht sich von selbst, dass Ihr Hauptaugenmerk darauf liegt, solche neuen Defekte so laut wie möglich zu verfolgen und Zeit schnell der Vermeidung von technischen Schulden zu widmen, sind ausgezeichnete Ideen.
Zusätzlich zum Fehler müssen Sie einen Prozess verwenden, um die Warnungen zu untersuchen und zu entscheiden, ob einige von ihnen zu Fehlern werden sollten.
Tags und Links continuous-integration static-analysis