© saicle/Shutterstock.com
Feinschliff zum regelmäßigen Build-Prozess

Softwarequalität in PHP-Projekten


Im dritten Teil dieser Serie schließen wir die Konfiguration des Jenkins-Servers ab. CodeSniffer, Copy/Paste Detector und Tools zur Erstellung einer Dokumentation werden Jenkins und dem Team zur Verfügung gestellt. Der abschließende Feinschliff an der ANT-Konfiguration rundet den Build-Prozess im Jenkins-Server ab.

Jenkins ist nach der im ersten Artikel der Serie beschriebenen Installation der Plug-ins vollständig vorbereitet, um ein PHP-Projekt zu überwachen und zu erstellen. Die Konfiguration der Projekte sowie statische und dynamische Softwaretests haben wir im zweiten Teil betrachtet. Nun ist es an der Zeit, den Feinschliff vorzunehmen.

Lint

Eine schnelle Out-of-the-box-Möglichkeit, PHP-Code zu testen, bietet PHP selbst. Hierzu wird PHP eine oder mehrere PHP-Dateien mit dem Zusatzparameter übermittelt, sie auf korrekte Syntax zu prüfen, ohne sie direkt auszuführen. Wir stellen diese Syntaxprüfung an den Anfang eines jeden Build-Prozesses; mit der Bedingung, den Build abzubrechen, sobald Syntaxfehler gefunden wurden. Beginnen wir damit, die build.xml um ein entsprechendes Target zu erweitern:

<target name="lint"> <apply executable="php" failonerror="true"> <arg value="-l" /> <fileset dir="${basedir}/src"> <include name="**/*.php" /> </fileset> </apply> </target>

Lines of Code

Eine der einfachsten Metriken für Software sind die ­Lines of Code (LOC). Hierbei werden schlicht die Codezeilen gezählt, die ein Projekt umfasst. Vereinfacht, sehr vereinfacht, gesagt, steigt die Anzahl der Bugs mit der Anzahl der Lines of Code – genauso, wie mit einer steigenden Anzahl von PKWs auf einer Autobahn die Wahrscheinlichkeit von Unfällen steigt. Ich persönlich nehme diese Zahl lediglich als reine Information für die Dokumentation, um ein Gefühl für das Projekt zu bekommen; das heißt, wie umfangreich ist es, wie viel muss tendenziell getestet werden etc. Eine Aussage über die Softwarequalität lässt sich meiner Meinung nach mit dieser Metrik allein nicht ableiten. Die build.xml wird zur Erfassung der Lines of Code wie folgt erweitert:

<target name="phploc"> <exec executable="phploc"> <arg value="--log-xml" /> <arg value="${basedir}/build/phploc.xml" /> <arg path="${basedir}/src" /> </exec> </target>

Style und Co.

Abgesehen von der Syntaxprüfung oder dem Zählen der Codezeilen gibt es noch mehrere Metriken, die man in Betracht ziehen kann und die es sich zu überprüfen lohnt. Im Folgenden möchte ich auf einige davon eingehen.

Copy/Paste Detector

Um zu verhindern, dass Codeteile unnötig dupliziert werden – was u. a. die Wartung erschwert, da Änderungen in mehreren Bereichen durchgeführt werden müssen –, binden wir in den Reviewprozess einen Copy/Paste Detector ein. Somit wird auch verhindert, dass gleiche Fehler in verschiedenen Codeteilen auftreten, was häufig dann passiert, wenn Code redundant an verschiedenen Stellen liegt. Der Copy/Paste Detector hilft uns somit sehr komfortabel, Codeteile aus verschiedenen Dateien zusammenzuziehen, denn kaum eine Person hat sämtliche Codezeilen und Funktionalitäten eines Projekts im Kopf. Die entsprechende Konfiguration der build.xml sieht wie folgt aus:

<target name="phpcpd"> <exec executable="phpcpd"> <arg value="--log-pmd" /> <arg value="${basedir}/build/logs/pmd-cpd.xml" /> <arg path="${basedir}/src" /> </exec> </target>

PHP-Copy/Paste-Detector-Output

Mit der Jenkins-Konfiguration und der gerade gezeigten PHP-Copy/Paste-Detector-Konfiguration entstehen die in Abbildung 1 gezeigte Übersicht sowie die in Abbildung 2 gez...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang