Da liefert uns die Ubuntu Community die 10.04LTS Version und wie bekommt die unserem CI Server? Die Antwort ist abhängig von den administrativen Eingriffen und dem Alter der Projekte. Kurz gesagt: “schlecht”.

Wichtige Änderungen:

1. PHP wird auf den 5.3er Zweig gehoben
2. Suns JAVA aus den offiziellen Quellen rausgenommen

Die Sun-Java Verbannung aus den supporteten Repos sorgt für eine Deinstallation der vorhandenen Sourcen und damit für das Aus unseres CruiseControl Dienstes. Nach den PHP Updates und dem Erhalten der vorhandenen php.ini folgten nette Warnings auf der Konsole, die aber schnell beseitigt werden konnten. Beachtet die Änderungen, die bei einigen Projekten auch zu unerwartetem Verhalten führen können.

Das sollte uns nicht abschrecken. Die Geschwindigkeitsvorteile und auch die neuen Möglichkeiten sind ausreichende Gründe die Anpassungen zu meistern.

Wie gelangt Ihr an die Sun-Java Installation (wann wird Oracle das Wording übernehmen)?

sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"
sudo apt-get update
sudo apt-get install sun-java6-jdk

Wenn Ihr die Lizenz bereits einmal bestätigt habt, läuft die Installation komplett durch. Viel Erfolg! Hinweise und Erfahrungen sind immer willkommen.

system requirements:

• Ubuntu (up to 8.04) minimal or Debian 5
• root access
• user for cruisecontrol runtime (this example: developer)

CruiseControl Install

apt-get update
apt-get install sun-java6-jdk
apt-get install unzip
apt-get install wget
apt-get install make

cd /opt
wget http://downloads.sourceforge.net/cruisecontrol/cruisecontrol-bin-2.8.2.zip
unzip cruisecontrol-bin-2.8.2.zip
mv cruisecontrol-bin-2.8.2 cc

useradd developer
chown -R developer /opt/cc

wget -O /etc/init.d/cruisecontrol http://phpundercontrol-server.googlecode.com/files/cruisecontrol-start-1.1
chmod +x /etc/init.d/cruisecontrol
update-rc.d cruisecontrol defaults

phpUnderControl Install

apt-get install php5
apt-get install php5-dev
apt-get install php-pear

pear upgrade PEAR
pear channel-discover pear.phpunit.de
pear channel-discover components.ez.no
pear config-set preferred_state beta
pear install --alldeps phpunit/phpUnderControl
pecl install xdebug
phpuc install /opt/cc

Versions

2009/10/01:
install ok: channel://pear.phpunit.de/PHPUnit-3.4.0
install ok: channel://pear.php.net/PHP_CodeSniffer-1.2.0
install ok: channel://pear.php.net/PhpDocumentor-1.4.3
install ok: channel://components.ez.no/Base-1.7
install ok: channel://pear.php.net/Image_GraphViz-1.3.0RC3
install ok: channel://pear.php.net/Log-1.11.5
install ok: channel://pear.php.net/DB-1.7.14RC1
install ok: channel://pear.php.net/MDB2-2.5.0b2
install ok: channel://pear.php.net/Mail-1.2.0b2
install ok: channel://pear.php.net/XML_Parser-1.3.2
install ok: channel://pear.php.net/Net_Socket-1.0.9
install ok: channel://pear.php.net/Auth_SASL-1.0.3
install ok: channel://components.ez.no/Graph-1.4.3
install ok: channel://pear.php.net/XML_Beautifier-1.2.0
install ok: channel://pear.php.net/Net_SMTP-1.3.3
install ok: channel://pear.phpunit.de/phpUnderControl-0.4.7

Was ist der Antrieb beim Coden? Für mich ist es der Spaß am Problemlösen, Knobeln, Macht über die Maschine zu bekommen- kurz Erfolgserlebnisse.

Woher soll man die nehmen, wenn in den tiefen Schichten einer Anwendung ohne sichtbare Erfolge entwickelt wird? Dafür wurden die Unit Tests erfunden. Sebastian Bergmann konnte es mit PHP und ohne diese Erfolgserlebnisse nicht mehr aushalten - er schrieb das Testframework PHPUnit.

Es gibt auch noch andere Versionen dieser Geschichte.

Example Projekt testen

Holen wir uns etwas Freude mit unserer Math Klasse und bringen die Unit Tests in den grünen Bereich.

Meilenstein 3

• Syntax berichtigen bis Unit Tests erfolgreich laufen
• Einfluß auf den Build in phpUnderControl erkunden

Den aktuellen Stand kann man sich auf den Testseiten von phpUnderControl anschauen. Aber als Reporting und Build Tool wird es nicht in den Workflow der Fehlerbeseitigung passen. Wir nehmen einfach wieder unsere Konsolenvariante. Genau genommen liegt hier auch der Anstoß für die Erstellung des Entwicklungsservers unter VirtualBox. Ich habe unter Vista64 einfach keine lauffähige CLI Version von PHP und damit auch PEAR hinbekommen.

Return to topic, nutzen wir doch einfach die Variante von Meilenstein 2 und aktivieren Überwachungskonsole …

cd /home/developer/example.phpuc/source
watch -n5 phpunit .

und Editor. Fehleranalyse: 2 Varianten sind immer zu bedenken. Erstens unsere Tests sind fehlerhaft oder der zu testende Code ist der Schuldige.

/home/developer/example.phpuc/source/tests/MathTest.php:92

Da haben wir die 1. Quelle und starten das Refactoring. Ich schlage vor jeder für sich schnell mal da durch.

cvs commit -m "alle Tests berichtigt"

Für Einsteiger sind schöne Beispiele für den Funktionsumfang von PHPUnit dabei. Schauen wir doch nochmal auf unsere Testseite und kaum zu glauben: GRÜN. Da ist es wieder dieses Erfolgserlebnis.

Ursachenforschung

  <target name="phpunit">
    <exec executable="phpunit" dir="${basedir}/source" failonerror="on">
      <arg line=" --log-xml ${basedir}/build/logs/phpunit.xml --log-pmd ${basedir}/build/logs/phpunit.pmd.xml --coverage-xml  ${basedir}/build/logs/phpunit.coverage.xml --coverage-html ${basedir}/build/coverage PhpUnderControl_Example_MathTest tests/MathTest.php"/>
    </exec>
  </target>

Die Testfehler verhinderten also ein erfolgreiches Build. Unsere Bemühungen tragen Früchte und wir haben ein Beispiel für Qualitätssicherung auf Unit Test Ebene.

Wer jetzt auch noch die letzten roten Punkte von der Karte haben will, der muß sich mit den Software Metrics auseinandersetzen und die anzeigten Probleme beseitigen. Dabei geht es um sehr wichtige Vorgaben, die die Teamarbeit ungemein unterstützen. Bei konsequenter Anwendung wird die Lesbarkeit und der Codingstil in der Quellen verbessert.

Am besten gefällt mir dabei der CRAP Index, der die Komplexität einer Funktion anhand der Anzahl ihrer möglichen Durchläufe bewertet. Vorbei die Zeiten schneller Dirty-Hacks, aber auch die der ungeliebten Pflege solcher Monster.

Bei aller Freude über die erfolgreiche Installation wollen wir den eigentlichen Antrieb, die monotonen Arbeiten macht phpUnderControl für uns, nicht vergessen. Es wird Zeit mal wieder Quellcode zu bearbeiten.

2. Meilenstein

• der Codingstyle für Codesniffer wird auf “Zend” festgelegt
• Refactoring: Code Style

Wir legen den Zend Style für unser Projekt einfach fest und lernen ihn dann on the fly.

Hier stellt sich gleich mal die Zwischenfrage: Sollte man den Codesniffer in die Versionverwaltung integrieren und “schlechte” Commits verhindern? Es kommt mal wieder auf die Rahmenbedingungen an. Codesniffers Speicherbedarf steigt mit dem Projektvolumen, zeitkritische BugFixes, Einsatz externer Tools alles das läßt sich geschickt administieren, aber wollen wir nicht eigentlich coden? Den Spaß am Refactoring gegen den Frust beim Commit abzuwägen ist stark projektabhängig.

Festlegung für das Example Projekt: PhpUnderControl dient zur Kontrolle und keine Sniffer Integration in die Versionsverwaltung.

Welche Codingstyles kennt den CodeSniffer?

developer@lamp:/opt/cc$ phpcs -i
The installed coding standards are PEAR, PHPCS, Squiz, Zend and MySource

Na wenn Zend schon drin ist brauchen wir nur noch den Schalter finden.

Usage: phpcs [-nwlsvi] [--report=<report>] [--report-file=<reportfile>]
    [--config-set key value] [--config-delete key] [--config-show]
    [--standard=<standard>] [--sniffs=<sniffs>]
    [--extensions=<extensions>] [--ignore=<patterns>]
    [--generator=<generator>] [--tab-width=<width>] <file> ...
        -n           Do not print warnings
        -w           Print both warnings and errors (on by default)
        -l           Local directory only, no recursion
        -s           Show sniff codes in all reports
        -v[v][v]     Print verbose output
        -i           Show a list of installed coding standards
        --help       Print this help message
        --version    Print version information
        <file>       One or more files and/or directories to check
        <extensions> A comma separated list of file extensions to check
                     (only valid if checking a directory)
        <patterns>   A comma separated list of patterns that are used
                     to ignore directories and files
        <sniffs>     A comma separated list of sniff codes to limit the check to
                     (all sniffs must be part of the specified standard)
        <standard>   The name of the coding standard to use
        <width>      The number of spaces each tab represents
        <generator>  The name of a doc generator to use
                     (forces doc generation instead of checking)
        <report>     Print either the "full", "xml", "checkstyle",
                     "csv", "emacs", "source" or "summary" report
                     (the "full" report is printed by default)
        <reportfile> Write the report to the specified file path
                     (report is also written to screen)

Na dann auf zu den Quellen und die Möglichkeiten durchgespielt:

cd /home/developer/example.phpuc/source/src
phpcs --standard=zend .

FILE: /home/developer/example.phpuc/source/src/Math.php
--------------------------------------------------------------------------------
FOUND 26 ERROR(S) AND 154 WARNING(S) AFFECTING 68 LINE(S)
--------------------------------------------------------------------------------
...

Refactoring beginnt

Da ist noch Refactoring nötig. Holen wir die Übersicht der Stylefehler auf die phpUnderControl Seiten. Den Aufruf von Codesniffer finden wir in der build.xml, leicht zu erkennen als <target  name=”php-codesniffer”>

<target name="php-codesniffer">
  <exec executable="phpcs" dir="${basedir}/source" output="${basedir}/build/logs/checkstyle.xml" error="/tmp/checkstyle.error.log">
    <arg line="--report=checkstyle --standard=zend src"/>
  </exec>
</target>

Den Parameter –standard=zend geändert und nach den commit ins CVS Repo sollte der nächste build getriggert werden.

cd /home/developer/example.phpuc
cvs commit -m "codesniffer auf zend umgestellt"

Beim nächsten Build Check sind wir dabei und finden kurz darauf unsere 26 Error(s) im Codesniffer Abschnitt des phpUnderControl. Gz - die erste Änderung in unserem Continuous Integration Prozess.

Die bemängelten Stellen werden wir mal gleich ausbessern. Ich benutze dazu am besten schnell 2 Konsolen.

watch -n5 phpcs --standard=zend .

Nummer 1 zeigt mir alle 5 Sekunden den aktuellen Stand. In der 2. bessere ich den Code aus. Etwas Find&Replace über die Variablennamen mit Ziffern, die langen Zeilen umgebrochen, die Klammerung an den Standard angepasst und plötzlich bleiben die Meldungen in Konsole 1 aus - geschafft.

Publishing

Das nächste CVS Commit sollte unseren Erfolg visualisieren.

cvs commit -m “CS Style erfüllt”

In der Datei habe ich:

.
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 *   * Redistributions of source code must retain the above copyright
 *     notice, this list of conditions and the following disclaimer.
 *
 *   * Redistributions in binary form must reproduce the above copyright
 *     notice, this list of conditions and the following disclaimer in
 *     the documentation and/or other materials provided with the
 *     distribution.
 *
 *   * Neither the name of Manuel Pichler nor the names of his
 *     contributors may be used to endorse or promote products derived
 *     from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
 * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
 * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
 * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
 * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
 * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
 * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
 * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGE.
 *
 * @package   Example
 * @author    Manuel Pichler

 * @copyright 2007-2008 Manuel Pichler. All rights reserved.
 * @license   http://www.opensource.org/licenses/bsd-license.php  BSD License
 * @version   SVN: $Id: Math.php,v 1.4 2009-05-13 21:51:26 developer Exp $
 * @link      http://www.phpundercontrol.org/
 */

/**
 * Simple math class.
 *
 * @package   Example
 * @author    Manuel Pichler

 * @author    Jens Klose
 * @copyright 2007-2008 Manuel Pichler. All rights reserved.
 * @license   http://www.opensource.org/licenses/bsd-license.php  BSD License
 * @version   Release: 0.4.7
 * @link      http://www.phpundercontrol.org/
 */
class PhpUnderControl_Example_Math
{
    /**
     * Adds the two given values.
     *
     * @param integer $firstVar Value one.
     * @param integer $secondVar Value two.
     *
     * @return integer.
     */
    public function add($firstVar, $secondVar)
    {
        return ($firstVar + $secondVar);
    }

    /**
     * Subtract param two from param one
     *
     * @param integer $firstVar Value one.
     * @param integer $secondVar Value two.
     *
     * @return integer.
     */
    public function sub($firstVar, $secondVar)
    {
        return ($firstVar - $secondVar);
    }

    /**
     * Not tested method that should be visible with low coverage.
     */
    public function div($firstVar, $secondVar)
    {
        $thirthVar = $firstVar / ($secondVar + $firstVar);
        if ($thirthVar > 14) {
            $forthVar = 0;
            for ($i = 0; $i < $thirthVar; $i++) {
                $forthVar += ($secondVar * $i);
            }
        }
        $fifthVar = ($forthVar < $thirthVar
                      ? ($thirthVar - $forthVar)
                      : ($forthVar - $thirthVar));

        $sixthVar  = ($firstVar * $secondVar
                      * $thirthVar * $forthVar * $fifthVar);

        $d = array(
                   $firstVar,
                   $secondVar,
                   $thirthVar,
                   $forthVar,
                   $fifthVar,
                   $sixthVar);

        $seventhVar = 1;
        for ($i = 0; $i < $sixthVar; $i++) {
            shuffle($d);
            $seventhVar = $seventhVar + $i * end($d);
        }

        $eighthVar = $seventhVar;
        foreach ( $d as $x ) {
            $eighthVar *= $x;
        }

        $thirthVar = $firstVar / ($secondVar + $firstVar);
        if ($thirthVar > 14) {
            $forthVar = 0;
            for ($i = 0; $i < $thirthVar; $i++) {
                $forthVar += ($secondVar * $i);
            }
        }
        $fifthVar = ($forthVar < $thirthVar
                     ? ($thirthVar - $forthVar)
                     : ($forthVar - $thirthVar));

        $sixthVar  = ($firstVar * $secondVar * $thirthVar
                   * $forthVar * $fifthVar);

        $d = array(
            $firstVar,
            $secondVar,
            $thirthVar,
            $forthVar,
            $fifthVar,
            $sixthVar
        );

        $seventhVar = 1;
        for ($i = 0; $i < $sixthVar; $i++) {
            shuffle($d);
            $seventhVar = $seventhVar + $i * end($d);
        }

        $eighthVar = $seventhVar;
        foreach ( $d as $x ) {
            $eighthVar *= $x;
        }

        return $eighthVar;
    }

    /**
     * Simple copy for cpd detection.
     */
    public function complex($firstVar, $secondVar)
    {
        $thirthVar = $firstVar / ($secondVar + $firstVar);
        if ($thirthVar > 14) {
            $forthVar = 0;
            for ($i = 0; $i < $thirthVar; $i++) {
                $forthVar += ($secondVar * $i);
            }
        }
        $fifthVar = ($forthVar < $thirthVar
            ? ($thirthVar - $forthVar)
            : ($forthVar - $thirthVar));

        $sixthVar = ($firstVar
            * $secondVar
            * $thirthVar
            * $forthVar
            * $fifthVar);

        $d = array(
            $firstVar,
            $secondVar,
            $thirthVar,
            $forthVar,
            $fifthVar,
            $sixthVar
        );

        $seventhVar = 1;
        for ($i = 0; $i < $sixthVar; $i++) {
            shuffle($d);
            $seventhVar = $seventhVar + $i * end($d);
        }

        $eighthVar = $seventhVar;
        foreach ( $d as $x ) {
            $eighthVar *= $x;
        }

        $thirthVar = $firstVar / ($secondVar + $firstVar);
        if ($thirthVar > 14) {
            $forthVar = 0;
            for ($i = 0; $i < $thirthVar; $i++) {
                $forthVar += ($secondVar * $i);
            }
        }
        $fifthVar = ($forthVar < $thirthVar
            ? ($thirthVar - $forthVar)
            : ($forthVar - $thirthVar));

        $sixthVar = ($firstVar
            * $secondVar
            * $thirthVar
            * $forthVar
            * $fifthVar);

        $d = array(
            $firstVar,
            $secondVar,
            $thirthVar,
            $forthVar,
            $fifthVar,
            $sixthVar
        );

        $seventhVar = 1;
        for ($i = 0; $i < $sixthVar; $i++) {
            shuffle($d);
            $seventhVar = $seventhVar + $i * end($d);
        }

        $eighthVar = $seventhVar;
        foreach ( $d as $x ) {
            $eighthVar *= $x;
        }

        return $eighthVar;
    }
}

Seltsam, die Codesniffer Ausgaben zeigen weiterhin Fehler an, obwohl die Message des Commits im Listing am Ende erscheint.

Aber haben wir den schon die Projektdateien unseres phpUnderControls aktualisieren lassen? Nein der Bootstrapper hat lediglich die build.xml erneuert. Da war doch was mit XML PingPong - genau in welche SteuerXML soll den nun der Projektupdate?

Das Projekt kennt seine Dateien besser und welche Versionsverwaltungen auch immer die Entwickler in Zukunft einsetzen wollen, welche Teilprojekte überhaupt aktualisiert werden sollen, alles das können die Entwickler am besten gleich in IHRER projektinternen build.xml verwalten. Ein neues Target muss her:

  <target name="build" depends="cvs-update,php-documentor,php-codesniffer,phpunit"/>
  <target name="cvs-update">
    <exec executable="cvs" dir="${basedir}/source" logerror="on">
      <arg line="update -P -d"/>
    </exec>
  </target>

Dieses Target auch noch ins build integriert als ersten Teil der depends Kette und ein neues commit des Projektes gewagt.

cvs commit -m "cvs update ins build"

Warten…
Erfolg! Zumindest die Codesniffer Meldungen haben wir beseitigt. Das komplette Build steht zwar noch auf rot, aber jetzt kann uns nichts mehr stoppen. Der nächste Meilenstein wartet.

Nützliche Links:

ANT Manual
CruiseControl Config
CodeSniffer
Deutsche ausführliche Anleitung von Nils Langner (PHP hates me)

Allzu gerne werden sie vernachlässigt - die Logdateien und alten Sicherungen. Unser phpUnderControl läuft nun schon einige Tage und ohne weitere Konfiguration wird das Example Projekt “php-under-control” alle 5 min neu getriggert und es erzeugt fleißig Dokumentationen und Auswertungen.

Da unser Continuous Integration Tool seinem Namen alle Ehre macht erzeugt es fortlaufend neue Dateien im ./artifacts Ordner. Das muss nicht auf jedem Server zum Problem führen. Bei richtiger Konfiguration sind diese Dateien sogar gewollt. Doch wer braucht schon die Nightly Builds der letzten 3 Jahre?

Also entweder das Aufräumen wird als Teil des Build Prozesses integriert und damit voll steuerbar oder die schnelle Variante die phpUnderControl mitliefert reicht für den Anfang.

phpuc clean -j php-under-control -k 10 /opt/cc

Der Befehl kürzt die Sammlung auf die letzten 10 Builds. Weitere Optionen findet ihr in der Doku.

Achtung: Dieses Aufräumen ist relevant für die angezeigte Statistik im Menüpunkt Metrics.

Feintuning wird nötig

Es wird also Zeit dem neuen Helfer genauere Anweisungen für sinnvollere Projektbegleitung zu geben.

Ab hier wird es jetzt so projektspezifisch, dass ich einige Vorgaben machen muss
1. Meilenstein:

• das example project wird in ein CVS Repository importiert
• phpUnderControl soll das CVS Repo überwachen
• das Projekt wird auf einem Arbeitsrechner ausgecheckt

Na dann mal los. CVS hatte ich neben weiteren Versionsverwaltungen ja bereits mit auf dem Entwicklungsserver installiert. Bleibt noch CVS Repository anlegen, Arbeitskopie des Projektes besorgen und dann ins CVS importieren.

mkdir /home/developer/cvs
cvs /home/developer/cvs init
cp -R /opt/cc/projects/php-under-control /home/developer
rm -R /home/developer/php-under-control/build
cd /home/developer/php-under-control/
cvs -d /home/developer/cvs import -m "agil begin" example.phpuc dev start

Es sollten einige positive Echos in der Konsole erscheinen. Ok, jetzt dieses Projekt als Arbeitskopie auschecken.

cd /home/developer/
cvs -d /home/developer/cvs/ checkout example.phpuc

Da wir die build.xml in der Versionsverwaltung integriert haben, müssen wir eine Besonderheit beim Konfigurieren von phpUnderControl beachten. Da bei der Überwachung nur die Änderung im CVS Repository als Auslöser eines neuen Builds dient, fehlt das Aktualisieren/Updaten der eventuell modifizierten build.xml bevor CruiseControl sie durch unsere fleißige Ameise (ANT) jagt. Aber da wir nicht die ersten sind, die das bemerken gibt es natürlich einen Ausweg.

Aber der Reihe nach: CVS Überwachung einbauen, build.xml updaten und dann ANT starten. Wo war das gleich nochmal? Ah ja, die Arbeitsanweisungen unseres Continuous Integration Tools stehen in der config.xml. Zeit diese unter die Lupe zu nehmen.

Jedes Projekt hat also seinen Abschnitt im XML. Hier mal ein Crashkurs für die Tag Elemente:

<project>

Dieses Element steht für ein Projekt und enthält in den eingeschlossenen Elementen die Informationen für das wann und wie eines Builds
Attribute:
name - eindeutiger Name innerhalb der CC Umgebung
buildafterfailed - [true|false] - aktiviert bei true weitere Builds auch nach Fehlern. Ist nützlich wenn der Fehler durch Systemprobleme (DB, Netwerk, …) entstand, aber erzwingt auch Wiederholungen wenn der Code wirklich nicht zu builden ist.

<schedule>

Dieses Element ist Pflicht und gibt an in welchem Intervall CruiseControl dieses Projekt tiggert. Außerdem enthält es den Aufruf der eigentlichen Buildprozesse.
Attributte:
interval - defaults ‘300′ (5 Minuten) - Sekunden bis zum nächsten Versuch

<modificationset>

Ist ein Intervall erreicht und das nächste Build steht an werden erst mal die hier eingetragenen Bedingungen gecheckt. Damit könnte man dieses Element als Filter betrachten. Es verhindert unnötige Buildprozesse oder startet bewußt z.B. Nightly Builds auch ohne Änderungen am Quellcode.
Attribute:

requiremodification - default ‘true’ - soll eine Änderung erst das Ereignis auslösen; alternativ kann dieses Attribut durch das Kindelement <alwaysbuild/> auch umgangen werden. Damit haben wir unseren Example Zustand gleich geklärt.
quietperiod - optional - gibt eine Zeitspanne in Sekunden an wie alt die erwartete Änderung mindestens sein soll. Das ist nützlich wenn großen Projekten oder langsamen Verbindungen die Versionsverwaltungen einen inkonsistenten Zustand haben könnten. Ich bin mir nicht sicher, ob das nur bei CVS passieren könnte, da andere ja atomar arbeiten.

<bootstrappers>

Hier können Anweisungen rein die noch vor jedem Build durchlaufen sollen. Da hatten wir doch Bedarf - genau - unser build.xml enthält ja die Anweisungen für einen neuen Buildprozess und bevor es vom ANT benutzt wird müssten wir die gewünschte und aktuellste Version im Projekt liegen haben. Das erledigen wir durch einen CVS update in diesem Element.

Na jetzt haben wir genug Theorie. Unser Meilenstein schreit nach Taten. Folgende Anpassungen müssen in die /opt/cc/config.xml Datei:

<?xml version="1.0"?>
<cruisecontrol>
  <project name="php-under-control" buildafterfailed="false">
    <listeners>
      <currentbuildstatuslistener file="logs/${project.name}/status.txt"/>
    </listeners>
    <modificationset>
      <cvs localWorkingCopy="projects/${project.name}/"/>
    </modificationset>
    <bootstrappers>
      <cvsbootstrapper
         localWorkingCopy="projects/${project.name}/"
         file            ="build.xml"
      />
    </bootstrappers>
    <schedule interval="60">
      <ant anthome="apache-ant-1.7.0" buildfile="projects/${project.name}/build.xml"/>
    </schedule>
    <log dir="logs/${project.name}">
      <merge dir="projects/${project.name}/build/logs/"/>
    </log>
    <publishers>
      <currentbuildstatuspublisher file="logs/${project.name}/buildstatus.txt"/>
      <artifactspublisher dir="projects/${project.name}/build/api" dest="artifacts/${project.name}" subdirectory="api"/>
      <artifactspublisher dir="projects/${project.name}/build/coverage" dest="artifacts/${project.name}" subdirectory="coverage"/>
      <execute command="/usr/bin/phpuc graph logs/${project.name} artifacts/${project.name}"/>
    </publishers>
  </project>
</cruisecontrol>

Ich habe gleich noch das Projekt “connectfour” entfernt. Testen wir die Änderungen indem wir im Browser nachsehen. Aber vorher noch eine CVS Version unseres Projektes in den CC Projektordner. Richtig wäre ein ordentlicher checkout, aber schneller ist:

cp -Rf /home/developer/example.phpuc/* /opt/cc/projects/php-under-control/

Der Meilenstein ist erreicht. Ich erhalte unter http://lamp:8080/cruisecontrol/buildresults/php-under-control

Projekt anlegen und einbinden

Was muss ich wo machen und bitte lange Dokumentationen vermeiden! Ok, es geht in 5 Sekunden.

phpuc example /opt/cc

Nach mehreren Zeilen Ausgaben meldet sich der freundliche Linux Prompt zurück und ein Test im Browser zeigt nach spätestens 5min ein neues Projekt in der Liste.

Farbe und Symbolik unseres php-under-control Projektes lassen nichts Gutes ahnen. In der Tat ist das mitgelieferte Example-Projekt mit Fehlern und schlechtem Codingstil behaftet - man will ja zeigen, was alles aufgedeckt wird.

Die Dokumentation ist auf dem neuesten Stand und die Anwendung kann als Beta den Markt erobern.
Schauen wir uns an was da im Hintergrund alles passiert, um unsere eigenen Projekte an diesem strengen Prüfer vorbei zu bekommen.

Als erstes erkunden wir die Arbeitsumgebung unseres Angestellten. Hat er überhaupt das Projekt richtig angelegt? Blindes Vertrauen schon in der Probezeit? Nein - also nochmal in den Konsolenausgaben unseres 5 Sekunden Projektes nachgeforscht:

finden wir alle relavanten Informationen. Der Workspace (project directory) wird also relativ unter projects/php-under-control angelegt. Ich habe auch gleich noch die entscheidenden Dateien markiert die offenbar miteinander korrespondieren.

• config.xml - (im root von CruiseControl /opt/cc) steuert die Projektüberwachung
• build.xml - (Ort ist nicht festgeschrieben) ist ein ANT build file

XML Ping Pong

Bei diesen XML Dateien steht man schnell mal vor der Frage: Wo packe ich das Auschecken von X oder das Kopieren von Y rein?

Ich habe da eine einfache Formel für die Grobabdeckung:

• Ist es Teil des eigentlichen Build Prozesses? -> build.xml
• Ist es zur regelmäßigen Überwachung des Projektfortschrittes nötig? -> config.xml

Beide Dateien stehen in engem Zusammenhang. Die config.xml muss die Ordnerstruktur der angelegten Builddateien und Logs kennen, um die entsprechenden Publisher zu steuern. Die Modificationsets der config.xml triggern auch erst ein Build und sind deshalb stark vom Projektzustand, wie z.B. Versionverwaltungssystemen, abhängig. Diese Abhängigkeit erklärt die Häufigkeit dieser beiden Dateien im obigen Konsolenmitschnitt.

Für die Arbeit mit Versionverwaltungen empfiehlt es sich, im Projektordner keine Dateien zu editieren. Das verhindert Merge Konflikte und damit fehlerhafte Builds, die die Entwickler bei sich lokal nicht nachvollziehen können. Dieser “Mitarbeiter” hat immer ein sauberes Arbeitsverzeichnis mit der aktuellen Programmversion, wenn wir uns daran halten.

Erfolgreiches Projekt

Bei unserem Example Projekt können wir uns eine Ausnahme gönnen. Der Spieltrieb sollte an dieser Stelle geweckt sein. Aktuell wird alle 5 Minuten die build.xml ausgeführt. Die entsprechenden Einstellungen dazu sind Thema des nächsten Artikels. Jetzt erst mal viel Spaß beim Ausprobieren.

Wie behalte ich die Übersicht über meine Projekte?
Wer kümmert sich um die Dokumentation?
Laufen die Tests noch?

Soll das Entwicklungstempo hoch gehalten werden und/oder agile Methoden zum Einsatz kommen, dann wird eine technische Lösung für diese Fragen gesucht.

PHP Projekte müssen nicht hilflos auf Ruby Tools schielen oder JAVA Lösungen beneiden. Es gibt interessante Anwendungen, die einen Tester, Builder und Dokumentator ersetzen. Dafür sind nur 237 Webquellen durchzuarbeiten, 793 weiterführende Links zu überschauen und Beta Versionen anzutesten.

Hört sich nicht sehr einladend an?
Ich habe in den letzen Tagen 3 mal ein phpUnderControl aufgesetzt und da die Sucherei nicht weniger wurde, mich gezwungen es zu dokumentieren. Für die von mir benutzten aktuellen Versionen ist es jetzt komplett nachvollziehbar.

Systemumgebung für diese Anleitung:

Ubuntu Server 8.10 (in VirtualBox installiert)

In den VirtualBox Einstellungen die Netzwerkkarte des Gastes als Hostinterface gesetzt für lokales Netzwerk zwischen Wirt und Gast.

Beim Ubuntu Setup ausgewählt:

• LAMP Server
• SSH Server

VirtualBox Netz erreichbar vom Host z.B. http://lamp
user account “developer”
root account aktiviert (sudo passwd root)

Die nächsten Systembefehle benötigen root Rechte und da es ein virtueller Rechner für lokale Entwicklung wird spricht nichts gegen die Arbeit als root. Alternativ kann gerne sudo vor jeden Befehl gesetzt werden. Für die Installation auf einem Arbeitsplatz empfehle ich eine Konsole mit “sudo -s” zur Root Shell zu machen.

optional wichtige Entwicklungstools:

• Subversion (apt-get install subversion)
• Git (apt-get install git-core)
• CVS (agt-get install cvs)

PHP vorbereiten:

apt-get install php5-cli php-pear php5-xdebug

Java JDK installieren

apt-get install sun-java6-jdk

Hier ist Interaktion angesagt, da die Nutzungsbedingungen akzeptiert werden müssen.

CruiseControl installieren

cd /opt
wget http://downloads.sourceforge.net/cruisecontrol/cruisecontrol-bin-2.8.2.zip
apt-get install unzip
unzip cruisecontrol-bin-2.8.2.zip
mv cruisecontrol-bin-2.8.2 cc
chown -R developer /opt/cc

Startsript anlegen:

cd /etc/init.d
touch cruisecontrol

Folgenden Inhalt einfügen:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          cruisecontrol
# Required-Start:
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: CruiseControl build loop.
### END INIT INFO

# CruiseControl Unix Startup Script Version
#
# based on http://confluence.public.thoughtworks.org/display/CC/UnixStartupScriptVersion1.x
# adapted for multiple projects
# also modified by Jerome Lacoste
#
# modifications for ubuntu-server installation by Jens Klose

########################################################################
# USER CONFIGURATION
#
# Fill in these values for your Cruise Control setup

# What user will Cruise Control run as?  The user will need permission to write and modify files
# in the next entries.
CC_USER=developer

# Where is the CC startup script located?
CC_INSTALL_DIR=/opt/cc

# In what directory is the config.xml file located for CC?
# default: CC_WORK_DIR=$CC_INSTALL_DIR
CC_WORK_DIR=$CC_INSTALL_DIR

# Where will the cruisecontrol.log file be located?
# default: CC_LOGFILE_DIR=$CC_INSTALL_DIR
CC_LOGFILE_DIR=$CC_INSTALL_DIR/logs

#######################
# ENVIRONMENT ADDITIONS

# Add environement variables here that are needed by your build.
# example:
export JAVA_HOME=/usr/lib/jvm/java-6-sun

# Add path to additional executables needed for project build.  See PATH entry below for base config.
# No additional action taken when blank.
PATH_ADDITIONS=

##############################
# CRUISE CONTROL PORT SETTINGS
# Port for Jetty reporting application.  You can access it by going to http://localhost:8080
# default CC_WEBPORT=8080
CC_WEBPORT=8080

# JMX port for webapp and Java Management eXtensions (JMX). http://localhost:8082
# Change only if this port is in use as the webapp will also need modification.
# default CC_JMXPORT=8082
CC_JMXPORT=8082

# RMI port for control via Java's Remote Management Interface (RMI)
# Leave blank to disable.
CC_RMIPORT=

########################################################################
# DO NOT MODIFY ENTRIES BELOW THIS LINE

NAME=cruisecontrol
DESC="CruiseControl - continuous integration build loop"

PATH=/sbin:/usr/sbin:/usr/bin:/bin

# add additions if variable has text defined
if [ -n "$PATH_ADDITIONS" ]; then
    PATH=$PATH_ADDITIONS:$PATH
fi
export PATH

CC_DAEMON=$CC_INSTALL_DIR/cruisecontrol.sh
CC_CONFIG_FILE=$CC_WORK_DIR/config.xml
CC_LOG_FILE=$CC_LOGFILE_DIR/cruisecontrol.log

CC_COMMAND="$CC_DAEMON -configfile $CC_CONFIG_FILE -webport $CC_WEBPORT -jmxport $CC_JMXPORT -rmiport $CC_RMIPORT"

# overwrite settings from default file
if [ -f /etc/default/cruisecontrol ]; then
    . /etc/default/cruisecontrol
fi

# does the executable exist?
test -f $CC_DAEMON || (echo "The executable $CC_DAEMON does not exist!" && exit 0)

if [ `id -u` -ne 0 ]; then
    echo "Not starting/stopping $DESC, you are not root."
    exit 4
fi

case "$1" in

    'start')
        cd $CC_INSTALL_DIR
        #echo "CC environtment at startup" > cc.startup.env
        #env >> cc.startup.env
        su $CC_USER -c "/bin/sh -c \"$CC_COMMAND >> $CC_LOG_FILE 2>&1\"" & RETVAL=$?
        echo "$NAME started with jmx on port ${CC_JMXPORT}"
        ;;

    'stop')
        # Get the PID output from the startup script
        if [ -f $CC_INSTALL_DIR/cc.pid ]; then
            CC_PID=`cat $CC_INSTALL_DIR/cc.pid`
        else
            echo "No cc.pid file found.  CC process may not be controllable from this script!"
        fi

        if [ -n "$CC_PID" ] && ps -p ${CC_PID} > /dev/null ; then
            kill -9 ${CC_PID}
            $0 status
            RETVAL=$?
        else
            echo "$NAME is not running"
            RETVAL=1
        fi
        ;;

    'status')
        # Get the PID output from the startup script
        if [ -f $CC_INSTALL_DIR/cc.pid ]; then
            CC_PID=`cat $CC_INSTALL_DIR/cc.pid`
        else
            echo "No cc.pid file found.  CC process may not be controllable from this script!"
        fi

        if [ -n "$CC_PID" ] && ps -p ${CC_PID} > /dev/null ; then
            echo $NAME \(pids $CC_PID\) is running
            RETVAL=0
        else
            echo "$NAME is stopped"
            RETVAL=1
        fi
        ;;

    'restart')
        $0 stop && $0 start
        RETVAL=$?
        ;;

    *)
        echo "Usage: $0 { start | stop | status | restart }"
        exit 1
        ;;

esac

exit 0;

Script testen:

root@lamp:/etc/init.d#chmod +x ./cruisecontrol
/etc/init.d/cruisecontrol start
cruisecontrol started with jmx on port 8082
root@lamp:/etc/init.d#

Im Browser testen:

http://lamp:8080/cruisecontrol/

Ok - dann: CruiseControl beenden:

/etc/init.d/cruisecontrol stop

Runlevel Einträge setzen:

update-rc.d cruisecontrol defaults

Output:

root@lamp:/etc/init.d# update-rc.d cruisecontrol defaults
 Adding system startup for /etc/init.d/cruisecontrol ...
   /etc/rc0.d/K20cruisecontrol -> ../init.d/cruisecontrol
   /etc/rc1.d/K20cruisecontrol -> ../init.d/cruisecontrol
   /etc/rc6.d/K20cruisecontrol -> ../init.d/cruisecontrol
   /etc/rc2.d/S20cruisecontrol -> ../init.d/cruisecontrol
   /etc/rc3.d/S20cruisecontrol -> ../init.d/cruisecontrol
   /etc/rc4.d/S20cruisecontrol -> ../init.d/cruisecontrol
   /etc/rc5.d/S20cruisecontrol -> ../init.d/cruisecontrol

Beim nächsten Neustart sollte die Startmeldung mit erscheinen.

An dieser Stelle hat man den fleißigen neuen Mitarbeiter bereits. Auch ohne phpUnderControl können jetzt Projekte verwaltet und mit ANT bearbeitet und deployed werden. Die weiteren Installationen bringen den PHP Entwicklern angepaßte Auswertungen, die auf den Logs der pear Tools beruhen.

Installation phpUnderControl, PHPUnit und weitere Tools:

2009/06 UpdateInfos: PHPUnit verlangt für die Installation einen aktuelleren PEAR Installer.
Fehlermeldung:
phpunit/PHPUnit requires PEAR Installer (version >= 1.8.1)
Lösung:
pear upgrade PEAR

Installation über pear erspart späteren Ärger mit PATH Anpassungen, installiert Codesniffer, PHPDocumentor und andere benötigte Tools gleich mit.

pear channel-discover pear.phpunit.de
pear update-channels
pear install phpunit/PHPUnit
pear install --alldeps Log
pear config-set preferred_state beta
pear install --alldeps pear/Image_GraphViz
pear channel-discover components.ez.no
pear install --alldeps phpunit/phpUnderControl
pear config-set preferred_state stable

Jetzt mal mit Ausgabe, um die Toolliste für manuelle Nachinstallationen festzuhalten.

root@lamp:~# root@lamp:~# pear install --alldeps phpunit/phpUnderControl
downloading phpUnderControl-0.4.7.tgz ...
Starting to download phpUnderControl-0.4.7.tgz (558,873 bytes)
.........................................................................done: 558,873 bytes
downloading Graph-1.4.2.tgz ...
Starting to download Graph-1.4.2.tgz (3,388,920 bytes)
...done: 3,388,920 bytes
downloading PHP_CodeSniffer-1.2.0RC1.tgz ...
Starting to download PHP_CodeSniffer-1.2.0RC1.tgz (282,807 bytes)
...done: 282,807 bytes
downloading PhpDocumentor-1.4.2.tgz ...
Starting to download PhpDocumentor-1.4.2.tgz (2,421,028 bytes)
...done: 2,421,028 bytes
downloading Base-1.6.1.tgz ...
Starting to download Base-1.6.1.tgz (178,245 bytes)
...done: 178,245 bytes
downloading XML_Beautifier-1.2.0.tgz ...
Starting to download XML_Beautifier-1.2.0.tgz (12,948 bytes)
...done: 12,948 bytes
downloading XML_Parser-1.3.2.tgz ...
Starting to download XML_Parser-1.3.2.tgz (16,260 bytes)
...done: 16,260 bytes
downloading XML_Util-1.2.1.tgz ...
Starting to download XML_Util-1.2.1.tgz (17,729 bytes)
...done: 17,729 bytes
install ok: channel://pear.php.net/PHP_CodeSniffer-1.2.0RC1
install ok: channel://pear.php.net/PhpDocumentor-1.4.2
install ok: channel://components.ez.no/Base-1.6.1
install ok: channel://pear.php.net/XML_Parser-1.3.2
install ok: channel://pear.php.net/XML_Util-1.2.1
install ok: channel://components.ez.no/Graph-1.4.2
install ok: channel://pear.php.net/XML_Beautifier-1.2.0
install ok: channel://pear.phpunit.de/phpUnderControl-0.4.7
root@lamp:~#

Erfolgserlebnis abholen:

root@lamp:~# phpuc -v
phpUnderControl 0.4.7 by Manuel Pichler.

So jetzt wird CruiseControl mit phpuc angereichert.

root@lamp:~# phpuc install /opt/cc
Performing CruiseControl task.
   1. Creating directory "webapps/cruisecontrol/images/php-under-control
   2. Creating directory "webapps/cruisecontrol/js

Performing modify file task.
   1. Creating backup "/webapps/cruisecontrol/buildresults.jsp".
   2. Modifying file "/webapps/cruisecontrol/buildresults.jsp"
   3. Creating backup "/webapps/cruisecontrol/index.jsp".
   4. Modifying file "/webapps/cruisecontrol/index.jsp"
...
  46. Creating file "/webapps/cruisecontrol/xsl/phpunit-pmd-details.xsl"
  47. Creating file "/webapps/cruisecontrol/xsl/phpunit-pmd-summary.xsl"
  48. Creating file "/webapps/cruisecontrol/WEB-INF/lib/php-under-control.jar"
root@lamp:~#

Der finale Start von phpUnderControl over CruiseControl

/etc/init.d/cruisecontrol start

Wie geht es weiter?

Endlich am Laufen beginnt die nächste Herausforderung - ein eigenes Projekt verwalten zu lassen. Das wird ein Thema der bald folgenden Dokumentationen sein.

Links zum Thema

• Die Installation unter CentOS 5
• Auch Debian basiert aber mit SVN Version von phpUnderControl (z.Z. buggy)