Lieferung 7.2 Werkzeugintegration/- kette mit Konfiguration für automatisiertes Build und Testen

Transkript

1 Lieferung 7.2 Werkzeugintegration/- kette mit Konfiguration für automatisiertes Build und Testen für das BMBF-Projekt Modellgetriebene agile Entwicklung für mobile Anwendungen (ModAgile Mobile) Arbeitspaket AP 7 Transformationen Arbeitspaketleitung arconsis Förderkennzeichen 01IS11012A-C Projektleitung andrena objects AG Jochen Winzen Partner andrena objects ag arconsis IT-Solutions GmbH FZI Forschungszentrum Informatik Autoren Johannes Tysiak Lieferdatum M21 Letztes Änderungsdatum Version 1.0 ModAgile Mobile L7.2 Werkzeugintegration/-kette mit Konfiguration für automatisiertes Build und Testen 1

2 1 Einleitung Die Zusammenarbeit im Team bringt für jedes Entwicklungsprojekt Herausforderungen mit sich. Insbesondere lange Zyklen zwischen der Integration der Arbeit einzelner Teammitglieder erschweren häufig das Zusammenführen von Änderungen und führen dazu, dass Teile des Codes aus oftmals zunächst unerklärlichen Gründen nur auf einzelnen Entwicklungsrechnern lauffähig sind. Gerade bei langwierigen Änderungen an Querschnittsfunktionalitäten, wie sie beispielsweise beim Wechsel auf neue SDK-Versionen von mobilen Entwicklungsplattformen auftreten können, treten solche und andere Probleme zu Tage. Um diese Probleme zu bewältigen, hat sich die Einführung eines Prozesses zur kontinuierlichen Integration (Continuous Integration) bewährt. 2 Kontinuierliche Integration Die Funktionsweis der kontinuierlichen Integration lässt sich idealerweise anhand eines Beispiels skizzieren. Ein Entwickler, der eine Softwareänderung durchführen möchte, besorgt sich zunächst den aktuellen Stand des Quellcodes aus dem Versionskontrollsystem und führt die notwendigen Änderungen durch. Da die kontinuierliche Integration ihre Stärken insbesondere dann entfalten kann, wenn eine hohe Durchsetzung von automatisierten Tests gegeben ist, besteht die Änderung sowohl aus einer Änderung des Produktivcodes als auch aus dem Anlegen oder Ändern von automatisierten Tests. Nachdem die Änderung abgeschlossen wurde, führt der Entwickler zunächst einen lokalen Build auf seiner Entwicklungsumgebung aus und führt die automatisierten Tests durch. Nur wenn Build und Tests erfolgreich waren, darf die Änderung in das Versionskontrollsystem eingebracht werden. Vor dem Checkin in das Versionskontrollsystem integriert der Entwickler zwischenzeitlich von anderen Entwicklern durchgeführte Änderungen. Wenn nach dieser Integration sowohl Build als auch Tests weiterhin erfolgreich sind, kann der Entwickler seinen Code den anderen Teammitgliedern zur Verfügung stellen. Jede Änderung des Codes im Versionskontrollsystem triggert einen automatischen Integrations-Build auf einem zentralen Build-Server, wo die Software nochmals gebaut wird und die automatisierten Tests laufen. Ein wichtiges Element für die Verwendung eines Prozesses zur kontinuierlichen Integration ist damit die Einrichtung eines zentralen Build-Servers, der eine Referenzumgebung für den Bau der Software und ihre Qualitätssicherung darstellt. Hiermit wird sichergestellt, dass es eine von Entwicklerrechnern unabhängige zentrale Instanz gibt, die zu jeder Zeit einen aktuellen, lauffähigen Softwarestand für jeden Projektbeteiligten bereithält, so dass auch nicht entwicklungsaffine Teammitglieder einen Einblick in den letzten Entwicklungsstand haben. Daneben wird der Build-Server in der Regel für die automatisierte Testausführung und die Erhebung von Softwarequalitätsmetriken eingesetzt, so dass zu jeder Zeit eine Aussage über die Produktqualität der zu entwickelnden Artefakte getroffen werden kann. Dies setzt zusätzlich die Auswahl und Definition geeigneter Metriken und Schwellwerte voraus, was jedoch im vorliegenden Dokument nicht näher betrachtet werden soll. In den letzten Jahren ist eine Vielzahl von Werkzeugen entstanden, die einen automatisierten Build, automatisierte Testausführung und Qualitätssicherung ermöglichen. Auf dem Markt ist weiterhin eine rege Weiterentwicklung feststellbar, so dass insbesondere in der Welt der Anwendungsentwicklung für mobile Endgeräte auch in Zukunft damit zu rechnen ist, dass die Anzahl der verfügbaren Werkzeuge weiter ansteigt. Für die im Rahmen des Projekts ModAgile Mobile entwickelten Werkzeuge ist es unter anderem auch aufgrund dieser Tatsache von essentieller Bedeutung, kein eigenes, geschlossenes System zu entwickeln, sondern exemplarisch eine Anbindung an etablierte Werkzeuge umzusetzen. Dabei ist zu berücksichtigen, dass diese Anbindung so gestaltet wird, dass ein leichter Austausch und eine einfache Erweiterbarkeit der verwendeten Werkzeuge von Drittherstellern möglich sind. ModAgile Mobile L7.2 Werkzeugintegration/-kette mit Konfiguration für automatisiertes Build und Testen 2

3 3 Werkzeugintegration für Build und Test Wie bereits in Kapitel 2 ausgeführt, soll im Rahmen von ModAgile Mobile kein eigenes Framework für den automatisierten Build und die automatisierte Testausführung innerhalb eines Prozesses der kontinuierlichen Integration entstehen. Anstatt dessen sollen sich die im Rahmen des Projektes entstandenen Werkzeuge einfach in bestehende Build- und Testinfrastrukturen integrieren, so dass eine Einführung der ModAgile Mobile Methodik einen möglichst geringen Bruch mit bisher genutzten Werkzeugen und Prozessen erfordert. Zunächst muss also betrachtet werden, welche Werkzeuge in der herkömmlichen Entwicklung mobiler Anwendungen eingesetzt werden. Dabei zeigt sich schnell, dass für jede Plattform (Android, ios, Windows Phone) eigene, an die Plattform angepasste Werkzeuge existieren, die jedoch häufig einen ähnlichen Funktionsumfang haben. Auf konzeptioneller Ebene lassen sich die Werkzeuge daher in die Schritte Build (Erzeugung von ausführbaren Artefakten aus dem Quellcode), Test (Automatisierte Ausführung von zuvor definierten Tests) und Qualitätsmessung (Ausführung von statischen Quellcode- Analysewerkzeugen und Ermittlung von Qualitätsmetriken) unterteilen. Änderung Testausführung Qualitätsmessung Build Abbildung 1: Vereinfachter Prozess der kontinuierlichen Integration Diese drei wesentlichen Schritte bleiben im Wesentlichen durch die ModAgile Mobile Methodik unangetastet. Bei Verwendung der ModAgile Mobile Methodik ist es jedoch erforderlich, einzelne im Rahmen des Projekts hergestellte Werkzeuge in diese Schritte zu integrieren. Diese zusätzlichen Werkzeuge sollen jedoch die herkömmlichen (plattformspezifischen) Werkzeuge nicht ersetzen, sondern lediglich ergänzen. Im Rahmen des Builds ist es erforderlich, dass der Quellcode der Software vollständig vorhanden ist. Bei Verwendung der ModAgile Mobile Methodik werden jedoch Teile des Codes aus Modellen generiert und sollten zwecks Vermeidung von Redundanzen nicht in das Versionskontrollsystem eingespielt werden, sondern im Rahmen des Builds generiert werden. Daneben werden auch für die automatische Testausführung Artefakte generiert, die vor dem Build-Schritt wie der Anwendungscode existieren müssen. Nicht zuletzt lassen sich auch auf Modellebene bereits Qualitätsmessungen durchführen, die eine plattformübergreifende Aussage auf die Qualität der Modellierung zulassen. ModAgile Mobile L7.2 Werkzeugintegration/-kette mit Konfiguration für automatisiertes Build und Testen 3

4 Im Folgenden soll die exemplarische, im Projekt verwendete Build-Infrastruktur aufgezeigt werden. Eine Integration in andere Build-Infrastrukturen ist möglich, wird jedoch nicht im Rahmen dieses Dokuments behandelt. 3.1 Build-Server Als Build-Server hat in den letzten Jahren das Open Source Projekt Jenkins CI 1 große Verbreitung in der Industrie so wie auch in nicht-kommerziellen Projekten gefunden. Jenkins ist ein Build-Server mit einer web-basierten Oberfläche, der durch ein modulares Plugin-System erweiterbar und anpassbar für eine Vielzahl von Zielplattformen eingesetzt werden kann. Die Menge an bereits existierenden Plugins ermöglicht eine einfache Integration vieler Entwicklungswerkzeuge. Jenkins wird aktuell bereits in vielen Projekten für die mobile Anwendungsentwicklung eingesetzt. Dabei wird ermöglicht, einen automatischen Build zeitabhängig oder abhängig von äußeren Ereignissen (wie beispielsweise Check-ins in das Versionskontrollsystem) zu planen, anschließend die automatische Testausführung zu triggern, die Testresultate einzusammeln und gemeinsam mit den Ergebnissen der Qualitätsmessung anzuzeigen. Abbildung 2: Jenkins CI Weboberfläche Jenkins kann als Build-Server für die gängigen mobilen Zielplattformen eingesetzt werden. Die eigentliche Ausführung des Builds, Tests und der Qualitätsmessung wird jedoch aus Jenkins lediglich gestartet und durch (weitgehend) plattformspezifische Werkzeuge durchgeführt. Die im Rahmen von ModAgile entwickelten Werkzeuge sind in Java entwickelt. Im kontinuierlichen Build wird daher eine Java-Laufzeitumgebung benötigt. Nachfolgend soll insbesondere betrachtet werden, wie ein einfaches Zusammenspiel der plattformspezifischen Werkzeuge mit den Werkzeugen der ModAgile Toolchain realisiert werden kann. 1 Jenkins CI: ModAgile Mobile L7.2 Werkzeugintegration/-kette mit Konfiguration für automatisiertes Build und Testen 4

5 3.2 Android Die Android-Entwicklung erfolgt in einer angepassten Variante der Java-Programmiersprache. Für die Entwicklung und die Aktivitäten auf dem Build-Server ist daher eine Java-Laufzeitumgebung erforderlich. Die grundlegenden Anforderungen der ModAgile-Werkzeugkette sind daher in jedem Android- Entwicklungsprojekt bereits erfüllt. Die Build-Orchestierung für Android wird in der Regel durch die Werkzeuge Apache Ant 2 oder Apache Maven 3 realisiert. Apache Ant ist ein Framework für die Build-Automatisierung, das ähnlich wie das aus der C-Entwicklung bekannte Make zur Orchestrierung von Build-Prozessen und ihren Abhängigkeiten verwendet werden kann. Im Gegensatz zu Make setzt Ant auf eine XML-basierte Syntax, um in Java definierte Build-Schritte zu konfigurieren. Der Kontrollfluss des Build-Prozesses ist dabei vollständig in der Hand des Entwicklers. Im Gegensatz dazu hat Maven einen vordefinierten Prozess für den Build von Softwareprojekten. Durch Einhaltung von durch Maven definierte Projektkonventionen soll eine komplexe Konfiguration vermieden werden. Die Komplexität von Maven-Konfigurationen hängt daher stark von der Einhaltung dieser Konventionen ein. Wie bei Ant erfolgt die Maven-Konfiguration XML-basiert. Das Android SDK bietet die Möglichkeit, Konfigurationsdateien für einen Ant-basierten Build zu generieren, so dass ein initialer Build für die kontinuierliche Integration schnell realisiert werden kann. Ant ist daher ein naheliegender Ansatz für die Integration der ModAgile Werkzeugkette in einen Android Buildprozess. Daneben lassen sich Ant Tasks (elementare Ausführungsblöcke in Ant) auch durch das Maven AntRun Plugin 4 in einen Maven-basierten Build-Prozess integrieren. Die Integration der ModAgile Werkzeuge zur Generierung von Anwendungs- und Testrümpfen kann daher idealerweise mit Ant realisiert werden. Dies ermöglicht eine minimalinvasive Integration in den Großteil der existierenden Build-Prozesse, so dass die Nutzung der vom spezifischen Projekt erforderten weiteren Werkzeuge (z.b. Testausführung, Qualitätssicherung) wie in Projekten ohne Verwendung der ModAgile Tools möglich ist. 3.3 ios Für die ios-entwicklung hat sich bislang noch kein Werkzeug für die Buildorchestrierung durchgesetzt. Im Wesentlichen sind für das Starten von ios-builds Kommandozeilenaufrufe notwendig, so dass eine Orchestrierung durch ein Shell-Skript möglich ist. Daneben ist AppleSkript eine Möglichkeit, die für den Build erforderlichen Schritte zu automatisieren. Häufig findet sich jedoch in der Praxis auch bei der ios- Entwicklung ein Ant- oder Maven-basierter Ansatz zur Buildautomatisierung. Die in Kapitel 3.2 aufgeführten Überlegungen treffen daher auch auf ios-projekte zu. Sollte ein Ant- oder Maven-basierte Ansatz nicht in Frage kommen, so stehen trotzdem mehrere alternative Lösungen zur Auswahl. Zum einen können die ModAgile-spezifischen Tätigkeiten innerhalb von Jenkins CI in einen eigenen Build-Schritt unter Verwendung von Ant ausgelagert werden. Alternativ dazu können die ModAgile-spezifischen Build-Schritte auch direkt über die Kommandozeile ausgeführt werden, was eine Integration in alle gängigen Werkzeuge für die Buildautomatisierung zulässt. Im Gegensatz zum Android-Build ist der ios-build jedoch nicht plattformunabhängig möglich. Die für den ios-build erforderlichen Tools werden von Apple bislang nur für Mac OSX zur Verfügung gestellt. Eine Buildautomatisierung für ios lässt sich daher nur auf Jenkins-Instanzen einrichten, die als Betriebssystem Mac OSX verwenden. In größeren Build-Umgebungen, in denen Jenkins im Master-/Slave-Betrieb mit mehreren Knoten eingerichtet ist, können auch gemischte Plattformen eingesetzt werden, wobei die ios- Builds jeweils nur auf Mac OSX Knoten ausgeführt werden können. 2 Apache Ant: 3 Apache Maven: 4 Maven AntRun Plugin: ModAgile Mobile L7.2 Werkzeugintegration/-kette mit Konfiguration für automatisiertes Build und Testen 5

6 4 Fazit Die Bereitstellung der ModAgile-Generierungswerkzeuge im Rahmen von Ant Tasks und auf Kommandozeilenebene erlaubt die einfache Integration der ModAgile-Entwicklungskette und methodik in Android- und ios-buildumgebungen. Es bleibt sichergestellt, dass bisher genutzte Werkzeuge für die Orchestrierung weiterhin eingesetzt werden können, wodurch die Einstiegshürde für die Buildautomatisierung möglichst niedrig gehalten wird. Auch die Erweiterbarkeit der Buildkette um neue, zum jetzigen Zeitpunkt noch nicht verfügbare Werkzeuge, bleibt ohne Einschränkung erhalten. ModAgile Mobile L7.2 Werkzeugintegration/-kette mit Konfiguration für automatisiertes Build und Testen 6