Abschlussbericht Erstellung eines automatisierten Build-Prozesses für Eclipse-RCP- Anwendungen am Fallbeispiel Control System Studio Christian Weber
Agenda Motivation (3-5) Vorgehen (6-7) Konzeptionelle Basis: Build-Prozess (8-13) Konzeptionelle Basis: Eclipse RCP (14-16) Implementation des Build-Prozesses (17-31) Fazit & Ausblick (32-34) 2/ 34
Motivation 1/2 Auslieferungsfähiges Produkt Fehlerermittlung Automatisierung Kontinuierliche Integration 3/ 34
Motivation 2/2 Eclipse-RCP-Anwendungen unterscheiden sich zu Standard-Java-Anwendungen Build-Werkzeuge für Java-Anwendungen können nicht verwendet werden Keine vollständige Vorlage zur Durchführung eines Build-Prozesses vorhanden 4/ 34
Zentrale Fragestellung Wie kann ein Build-Prozess umgesetzt werden, der kontinuierliche Integration bei der Entwicklung von Eclipse-RCP-Anwendungen ermöglicht? 5/ 34
Vorgehen (Diplomarbeit) Thema: Build-Prozess Automatisierung der RCP Control System Studio Einlesen in die Thematik und Konkretisierung des Ziels der Diplomarbeit Erstellen des Build-Prozesses (Tagebuch) und anschließende Niederschrift (Plan) 6/ 34
Vorgehen (Build-Prozesses) Identifikation der Rahmenbedingungen und Anforderungen beim DESY Inkrementelles Vorgehen: Implementation einzelner Aspekte des Build- Prozesses Feedback durch die Entwickler nach Implementation eines Aspekts 7/ 34
Begriff: Build Doppeldeutigkeit: build a release vs. release a build Eigene Definition: Ein Build-Prozess ist eine Serie von Schritten, die aus den Quellelementen eine getestete und auslieferbare Software erzeugt. 8/ 34
Konstruktion des Build-Prozesses 1/2 Höhere Priorisierung in aktuellen Vorgehensmodellen der Softwareentwicklung Build-Patterns: Private System Build, Integration Build und Release Build [Berczuk, Stephen P. ; Appleton, Brad: Software Configuration Management Patterns: Effective Teamwork, Practical Integration.] 9/ 34
Konstruktion des Build-Prozesses 2/2 CRISP-Bedingungen: [Clark, M. : Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Applications] Complete Repeatable Informative Schedulable Portable 10 / 34
Build-Phasen 11 / 34
Kontinuierliche Integration 12 / 34
Kontinuierliche Integration Risiken der Integration werden reduziert Es ist jederzeit möglich, eine auslieferungsfähige Software zu erstellen Überblick über das Projekt wird verbessert Durch sofortiges Feedback steigt die Motivation der Entwickler 13 / 34
Fallstudie: DESY Hamburg Infrastruktur für Kontrollsysteme Eclipse-RCP-Anwendung bestehend aus 376 Plug-ins (166 Eigenentwicklung) Bisher: manuelle Ausführung des Build-Prozesses, keine Test-Ausführung 14 / 34
Eclipse-RCP-Anwendung besteht aus: Plug-in / Fragment aus Eigenentwicklung oder der Target Platform Feature Application (Plug-in) Product Definition (Plug-in) 15 / 34
Architektur eines RCP-Plug-ins src Manifest.MF build.properties.classpath.project 16 / 34
Implementation des Build-Prozesses 17 / 34
Realisierung: Anforderungen: Vorbereitung, Ausführung und Verknüpfung der Build-Phasen plattformunabhängige und relative Beschreibung des Build-Prozesses Situation: Batch-Skripte für Eclipse Version 3.3 Lösung: ANT 18 / 34
Realisierung: 1/3 Situation: Die Quellelemente befinden sich in vielen verschiedenen Ordnern Abhängigkeiten sind in den Quellelementen definiert Beim DESY keine Versionierung der Target Platform 19 / 34
Realisierung: 2/3 Anforderungen: Minimale Beschreibung der Quellelemente und ihrer Positionen Änderungen in den Abhängigkeiten sollen automatisch berücksichtigt werden Ausgabe fehlender Quellelemente Unterstützung von SVN / CVS als Versionsverwaltung Versionierung der Target Platform 20 / 34
Realisierung: 3/3 Werkzeuge: ANT + CVS Task (keine Abhängigkeitsanalyse) PDE + Map-Dateien (Abhängigkeitsanalyse / ausführliche Beschreibung der möglichen Positionen der Quellelemente) Buckminster (Abhängigkeitsanalyse / minimal Beschreibung der möglichen Positionen der Quellelemente) 21 / 34
Realisierung: 1/2 Anforderungen: Erstellung des Produkts anhand der Produktdefinition Weitere Produkte sollen durch den Austausch der Produktdefinition möglich sein Keine Anpassung des Quellcodes 22 / 34
Realisierung: 2/2 Werkzeuge: PDE-Build (Produkterstellung über vorhandene dynamische Ant-Skripte) Buckminster (Produkterstellung mit Hilfe einer zu erstellenden CSPEX-Datei + Ant-Skript / Verwendung Action create.site und P2 Director) Ant4Eclipse (Produkterstellung über ein zu erstellendes Ant-Skript unter Verwendung der Ant4Eclipse-Tasks) 23 / 34
Realisierung: 1/5 Situation: JUnit unterstützt keine headless Ausführung von Plug-in Tests Tests sind im zu testenden Plug-in Keine Testsuite vorhanden 24 / 34
Realisierung: 2/5 Anforderungen: Headless Ausführung von JUnit4 Plug-in Tests Trennung der Abhängigkeit des zu testenden Plug-ins vom Test-Framework Erstellen einer Testsuite, welche sich durch eine hohe Benutzbarkeit auszeichnet 25 / 34
Realisierung: 3/5 Werkzeuge für die Testausführung: Eclipse + JUnit Listener (PDE Test Utilities) Eclipse Test Framework 26 / 34
Realisierung: 4/5 Positionen der JUnit Plug-in Tests: Möglichkeit 1: Im zu testenden Plug-in Möglichkeit 2: In einem zweiten Plug-in Möglichkeit 3: In einem Fragment des Plug-ins 27 / 34
Realisierung: 5/5 Realisierung der Testsuite: Möglichkeit 1: Über ein Ant-Testskript Möglichkeit 2: Über ein selbst entwickeltes Test-Plug-in: org.csstudio.testsuite 28 / 34
Ergebnis: Implementation des Build-Prozess 29 / 34
Realisierung: Kontinuierliche Integration 1/2 Anforderungen an den CI-Server: Konfiguration über ein Web-Interface Ermittlung der Änderungen über einen Update-Mechanismus Definition von Abhängigkeiten zwischen verschiedenen Build-Projekten Benutzerverwaltung 30 / 34
Realisierung: Kontinuierliche Integration 2/2 Werkzeuge: CruiseControl Nicht ausschließlich über Web konfigurierbar Keine Bereitstellung der veränderten Quellelemente Keine Definition von Abhängigkeiten zwischen mehreren Build-Projekten Hudson 31 / 34
Fazit 1/2 Diplomarbeitsziel konnte erreicht werden Schwachpunkte der Werkzeuge: Ohne Anpassung unterstützt keines der Werkzeuge die Testausführung von JUnit4 Plug-in Tests Viele unterschiedliche Werkzeuge 32 / 34
Fazit 2/2 Indirekte positive Ergebnisse: Architekturfehler konnten durch den neuen Build-Prozess entdeckt werden Versionierung der Target Platform Die Trennung von zu testenden Plug-in und Testcode verbessert die Architektur der Anwendung 33 / 34
Ausblick Neue Werkzeuge: Eclipse Test Framework und Buckminster unterstützen JUnit4 Plug-in Tests ab Version 3.6 Build-Prozess: Mögliche Erweiterungen zur Ermittlung einer Testabdeckung soweit Werkzeuge diese für Eclipse-RCP-Anwendungen unterstützen 34 / 34