Continuous Integration mit Flex/Actionscript 3: CI

Im letzten Teil hatten wir ein kleines Demo Projekt mit Ant gebaut. Damit können wir es nun in einem Continuous Integration System (CI) laufen bauen lassen. Ein CI kompiliert Projekte, führt diverse Metriken aus und gibt eine Rückmeldung über das Ergebnis. Zu den bekannten CIs gehören Hudson bzw. der Nachfolger Jenkins und Teamcity. Diese CIs sind Open Source oder frei verfügbar für eine geringe Anzahl an Nutzern.

Wir benutzen hier Jenkins, gerade in der Java-Welt wohl das bekannteste CI. Um das Ganze auszuprobieren kann man Jenkins erstmal lokal installieren. Das ist erstaunlich einfach:

1. Das Package für die eigene Plattform von http://jenkins-ci.org/ herunterladen und eventuell entpacken
2. In der Shell das entpackte Verzeichnis wechseln und dort wo jenkins.war liegt java -jar jenkins.war aufrufen. 
3. Nach einem kurzen Moment ist Jenkins unter http://localhost:8080/ im Browser ereichbar.

Zum Probieren starte ich den Jenkins lokal immer per Hand, natürlich kann er auch als Service laufen.

Richten wir nun unser Projekt ein:

1. Im Jenkins auf "New Job" klicken, den Job benennen und "freestyle-software project" auswählen
2.  Im darauf folgenden Menü "Invoke from Ant" auswählen, bei den anderen Punkte sollten die Einstellungen ok sein
3. Speichern
4. Nun auf "Build now" klicken. Der Build wird failen, aber das Verzeichnis wird angelegt in das wir unser Projekt kopieren können
5. Das Demo Projekt nach jenkins/jobs/DER NAME DES JENKINS JOB/workspace kopieren. Bei mir liegt Jenkins unter /var/lib
6. Erneut auf "Build now" klicken.

Yeah, Jenkins baut das Demo!

Continuous Integration mit Flex/Actionscript Teil 2: Ant

Ersteinmal muss man Ant auf seinem System installieren. Dazu sind folgende Schritte nötig:

1.  Ant herunterladen von http://ant.apache.org/bindownload.cgi und entpacken (an einen beliebigen Ort)
2.  Java muss installiert sein. Eventuell also Java installieren.
3.  Enviroment Variablen setzen. Bei Windows über System, Umgebungsvariablen und bei X-Systemen über das editieren der .bash_profile im home folder. Es muss das JAVA_HOME zur Java Installation zeigen, ANT_HOME dorthin, wo Ant enpackt wurde und  ${ANT_HOME}/bin (Unix) bzw.  %ANT_HOME%/bin (Win) sollten zum PATH hinzugefügt werden.

Zum Beispiel unter Linux:

vi /home/milena/.bash_profile
export $ANT_HOME=/home/milena/apps/ant
export PATH=$ANT_HOME/bin:$PATH
export JAVA_HOME=/usr/lib/jvm/java-6-sun-1.6.0.20/


Wenn ihr nun in der Console ant -version eingebt, solltet ihr eine sinnvolle Meldung mit einer Versionsnummer erhalten. Ant geht also schon mal, nun muss nur noch das Projekt konfiguriert werden.
Adobe hat beim Flex SDK schon entsprechende AntTasks mitgeliefert. Und man kann reine ActionScript Projekte ebenfalls mit dem Flex SDK kompilieren.
Für Ant benutzt man als Konfiguration ein build file (build.xml) indem steht was zu kompilieren ist und was es sonst noch für Tasks für Ant zu machen gibt. Außerdem benutzt man noch ein properties File das System spezifisch ist und eure Pfade enthält. Ihr könnt also in eurem Projekt auf höchster Ebene eine Datei namens build.properties anlegen. Dort sollte mindestens das FLEX_HOME definiert sein, was dann so aussieht:

FLEX_HOME=C:/Program Files/Adobe/Flash Builder Burrito/sdks/4.1

Hilfreich ist auch das src Directory

SRC_DIR =${basedir}/src 

Es können auch noch Pfade zum Folder wo die Libraries liegen angegeben werden usw. Es ist eure Entscheidung, ob ihr die Pfade auslagert oder in der build.xml direkt angebt.

Nun kommt auch schon das Build File. Legt eine Datei namens build.xml auf der gleichen Ebene wie die build.properties an. Die Angaben beziehen sich auf mein Sample bei GitHub.
Gehen wir die Teile der build.xml durch.
Als erstes sagt ihr Ant was es als default Task ausführen soll:

<project name="Flex Ant Tasks Build Script" default="compile flex project">

Dann verweist ihr auf eure properties für die Pfade:

 <property file="build.properties"/>

Nun definiert ihr einen Task zum Aufräumen, altes Verzeichnis löschen und neu erzeugen 

 <taskdef resource="flexTasks.tasks" classpath="${FLEX_HOME}/ant/lib/flexTasks.jar"/>
  <target name="init">
   <delete dir="bin-debug"/>
   <mkdir dir="bin-debug" />
  </target>

Nun das eigentliche Kompilieren:

 <target name="compile flex project" depends="init">
  <mxmlc file="${SRC_DIR}/AntSample.mxml" output="bin-debug/AntSample.swf">
    <load-config filename="${FLEX_HOME}/frameworks/flex-config.xml"/>
    <source-path path-element="${FLEX_HOME}/frameworks"/>
    <compiler.debug>false</compiler.debug>
   </mxmlc>
  </target>

Dann schliesst ihr das Anfangstag:

</project>


 Super! Das war es auch schon für mein Sample Projekt. Das findet ihr bei GitHub und es sollte leicht sein es auf ein eigenes kleines Projekt zu übertragen.

Continuous Integration mit Flex/Actionscript 1: Einführung

In einigen Artikeln möchte ich den Weg beschreiben, von einem Projekt aus der IDE (Flashbuilder, Idea, FDT …) zu einem Projekt zu migrieren das auf einem Continuous Server regelmäßig gebaut werden kann.

Wieso sollte man überhaupt automatisieren und auf einem Continuous Integration (CI) System bauen? Wenn man alleine auf einem Rechner an einem kleinen Projekt arbeitet und aus der IDE heraus baut ohne dass Probleme auftreten, muss das vielleicht gar nicht sein. Arbeitet man aber mit mehreren Leuten an einem Projekt (die vielleicht auch gar keine entsprechende IDE haben), wechselt zwischen verschiedenen Rechnern/Betriebssystemen oder hat Abhängigkeiten (Libraries, Backend, Theme swcs), die sich oft ändern, treten sicher Probleme auf. In der einen Umgebung funktioniert etwas, in der anderen nicht, jemand macht abends eine Änderung und morgens kann keiner weiter arbeiten, weil das Projekt nicht mehr kompiliert. Der Kunde meldet Fehler und man ist nicht sicher in welcher Version diese Fehler aufgetreten/gefixt worden sind. Vielleicht muss man auch öfter ältere Projekte anfassen, wo man erstmal lange herumbastelt bis sie wieder in der IDE laufen? Oder es fehlen dauernd Dateien, wenn man ein Zip mit der “fertigen” Software zusammen stellt? Klingen diese Probleme bekannt ist es an der Zeit, sich mit Buildtools, Versionskontrolle und CI zu befassen.

Buildtools
Buildtools können Code (in unserem Fall ActionScript) kompilieren, Packages (zum Beispiel zips mit swfs und Assets) zusammen stellen, Versionen von Abhängigkeiten verwalten und auch die Versionierung der eigenen Software managen. Das ist schon einiges mehr als die IDE kann und besonders bei komplexeren Systemen eine Hilfe. Durch Buildtools kann man mit CI Systemen arbeiten. Um los legen zu können muss man sich nun für ein Tool entscheiden. Bekannte Buildtools, die für den ActionScript Bereich in Frage kommen, sind Ant und Maven. Es gibt auch noch Project Sprouts, buildr (Ruby und RubyGems Basis) und Gradle, die ActionScript Projekte bauen können.

Sollte man nicht gerade an einem Projekt arbeiten, dass die weniger bekannten Tools benutzt ,würde ich bei Ant oder Maven bleiben. Ant ist das verbreitetere System, Adobe unterstützt und nutzt Ant. Maven ist in der Java Welt inzwischen sehr populär und kann mit den FlexMojos für ActionScript genutzt werden.

Maven bringt eine großartiges Versionsmanagement für Abhängigkeiten mit und ich würde für große Projekte daher immer Maven nehmen. Maven ist allerdings komplizierter zu konfigurieren und beruht viel auf Konventionen. Um ein eher kleines Projekt CI fähig zu machen werde ich hier Ant benutzen, da es weniger aufwendig ist. Im nächsten Teil werde ich Ant installieren und ein HelloWorld Projekt aus der IDE mit Ant bauen.

FFK11

Einen großen Dank an Organisatoren und Teilnehmer der FFK11. Eine gelungene Konferenz mit den Themenschwerpunkten RIA und Flash. Ich habe etwas zum Thema Software Metrics und Continuous Integration gesagt.

Software Metrics and Continuous Integration

View more presentations from Milena Reichel