Da ist etwas faul im Bau!

Hassen Sie es nicht auch, wenn etwas die Erstellung Ihrer Software stört? Build-Probleme verursachen zusätzliche, ungeplante Arbeit. Sie scheinen immer dann aufzutreten, wenn Sie sich beeilen, ein anderes Problem zu lösen. Oft geht der Build aus irgendeinem Grund kaputt, der nichts mit dem zu tun hat, was Sie gerade tun. Es kann also ziemlich frustrierend sein, wenn man seine Arbeit unterbrechen muss, um herauszufinden, was die Ursache für den Buildfehler ist, das Problem beheben und den Build neu starten muss (in der Hoffnung, dass man nur ein Problem zu lösen hat).

Ich bin heute auf dieses Problem gestoßen, als ich einige Open-Source-Pakete neu erstellt habe. Vor ein paar Monaten haben wir unsere Kopie von OpenSSL auf Version 1.0.0 aktualisiert, aber wir haben nicht alle Pakete, die davon abhängen, neu erstellt. Als ich den Subversion-Client neu erstellen wollte, um einen Fehler zu beheben, stellte ich fest, dass der Subversion-Build aufgrund der Tatsache, dass OpenSSL 1.0.0 einige inkompatible Änderungen mit sich brachte, fehlerhaft war. Ich brauchte nicht lange, um die Korrektur zu finden, da dieses Problem schon vor Monaten behoben worden war, und eine einfache Websuche fand sowohl den Fehlerbericht als auch die Korrektur. Aber es war trotzdem ziemlich ärgerlich, auf dieses Problem zu stoßen, als ich gerade versuchte, das Produkt neu zu erstellen.

Ich habe hier keinen brillanten Vorschlag zu machen. Aber ich habe eine Beobachtung gemacht, und zwar, dass Maschinenzeit jetzt im Überfluss vorhanden ist. Vielleicht sollten wir einfach jede Nacht unsere gesamte Software neu erstellen. Dadurch werden Build-Probleme erkannt, wenn die Probleme noch frisch in den Köpfen der Beteiligten sind.

Falls Sie einige manuelle Schritte in Ihrem Erstellungsprozess haben, ist die Entscheidung, diese häufig neu zu erstellen, ein guter Anreiz, sie zu eliminieren. Manuelle Schritte sind eine häufige Fehlerquelle.

Softwaretester neigen dazu, Software nach dem Testen nur ungern umzubauen. Sie sehen darin eine Gelegenheit, neue Fehler einzuführen. Ich habe gerne genug Vertrauen in meine Build-Tools (Compiler, Linker, Makefiles), dass ich sie jederzeit neu erstellen kann. In Anbetracht der Tatsache, dass wir in Hochsprachen arbeiten, müssen wir Vertrauen in unsere Build-Tools haben. Aber in einem schrittweisen Entwicklungsprozess ist genug Platz für beide Ansichten.

Wenn Sie Vorschläge haben, wie man die Softwareentwicklung so steuern kann, dass die Wahrscheinlichkeit, dass ein Build kaputt geht, oder der Aufwand für die Korrektur von Build-Problemen minimiert wird, fügen Sie bitte Ihre Kommentare zu diesem Beitrag hinzu.