Gründe für den Fehlschlag eines Builds

7

Als Bauingenieur bin ich ständig auf der Suche nach neuen und interessanten Möglichkeiten, unseren Build-Prozess zu verbessern - und dazu gehört auch die Suche nach neuen und interessanten Möglichkeiten, unsere Builds zu versagen!

Ich muss noch eine kanonische Liste von Gründen finden, um einen Build zu scheitern ... also denke ich, es ist Zeit, einen zu erstellen. In diesem Sinne:

Welche Build-Time-Prüfungen - offensichtliche und kreative - haben Sie Fehler Builds gesehen?

    
Brian Laframboise 10.02.2010, 18:41
quelle

12 Antworten

4
  • Kompilierungsfehler
    • Produktionscode
    • Testet Klassen
  • Jede Art von Testversagen:
    • Komponententests
    • Integrationstests
    • Funktionstests
    • Leistungstests
  • Nicht übereinstimmende Qualitätsprüfungen:
    • Kodierungskonvention (Checkstyle)
    • Testabdeckung (Clover, Cobertura usw.)
    • Fehlererkennung (FindBugs, PMD, Hammurapi)
    • Kopieren Sie die Erkennung der Erkennung (CPD, Symian)
    • Binärkompatibilität (Clirr)
Pascal Thivent 10.02.2010, 19:12
quelle
7
  • Kompilierungsfehler
  • Komponententests
  • Integrationstests
  • Systemtests
  • Namenskonventionen
  • Codequalität
  • Regressionstests
flybywire 10.02.2010 19:00
quelle
5

Nicht genehmigte Eincheckvorgänge in Build. Dinge wie eingecheckter Code, der keinem Workitem oder einer Fehlerbehebung zugeordnet ist.

    
GWLlosa 10.02.2010 18:46
quelle
2

Fehler bei automatisierten Qualitätsprüfungen (FxCop, etc.).

    
GWLlosa 10.02.2010 18:44
quelle
2

Komponententestfehler.

    
Brian Laframboise 10.02.2010 18:53
quelle
2

In seinem Artikel zur Einführung von Continuous Integration präsentierte Martin Fowler Fehler beim Ausführen der Einheitentests der Anwendung als ein zwingender Grund, einen Build fehlzuschlagen.

    
shadit 04.04.2010 00:12
quelle
1

Fehler beim Kompilieren Warnung

    
zr. 10.02.2010 18:45
quelle
1

Einführung einer zyklischen Abhängigkeit zwischen Modulen (zB Java-Pakete).

    
Brian Laframboise 10.02.2010 18:46
quelle
1

Mein Unternehmen tut dies eigentlich nicht, aber mit einer großen Legacy-Codebasis wie der unseren wäre es gut, bei undokumentierten Änderungen zu scheitern. Ohne ein Fehlerticket irgendeiner Art würde unsere QA-Abteilung nicht wissen, um die Änderungen zu testen, und das ist beängstigend!

    
David V McKay 10.02.2010 18:47
quelle
1

Überprüfen Sie, ob doppelte Klassen (gleicher Paket- und Klassenname) in verschiedenen JAR-Dateien (Java) vorhanden sind.

    
Alexey Kalmykov 10.02.2010 18:48
quelle
0

Die Codeabdeckung verringert oder unterschreitet einen akzeptablen Schwellenwert.

    
Brian Laframboise 10.02.2010 18:59
quelle
0

Etwas so Einfaches wie eine Überprüfung des Kompilierungsfehlers sollte als obligatorisch betrachtet werden, nuff sagte .

Check-ins, die zu kaputten Builds führen, sollten inakzeptabel sein, obwohl die traurige Wahrheit ist, dass viele Organisationen solche akzeptieren.

Wenn die Kompilierung fehlschlägt:

  • ... Sie werden keine Binärdatei verwenden oder ausführen.
  • ... Sie können keine Tests und Analysen durchführen, um sicherzustellen, dass es funktioniert.
  • ... Sie können keine weiteren Überprüfungen durchführen, um das Projekt zu erstellen.
  • ... Sie können Ihrem Kunden nicht gefallen, weil Sie nichts zu zeigen haben.

Warum? WEIL DAS GEBILD GEBROCHEN ist.

    
Spoike 10.02.2010 20:23
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Android Spiel mit konstanter FPS?