Sommer Sitzung 12
| Thema | Stichworte | Material ___________________________ |
| Überblick | Release Engineering; konkret: Versionskontrolle, Tests, Dokumentation, CRISP builds und continuous integration | Beispiele und Literatur: Home |
| Einordnung | Jetzt komplett Funktionalität im Code fertig; quasi alles zusammenpacken | — |
| Versionskontrolle | Wo soll quasi der Code überhaupt sein, damit man selbst oder jemand anderes ihn später weiterentwickeln, wiederverwenden, etc. kann; etabliertes System: Versionskontrolle, z.B. auf einem externen Server; Grundidee: Änderungen am Code nicht nur speichern, sondern in Versionskontrollsystem ablegen (committen); Vorteile und Möglichkeiten durch Versionskontrolle? – man kann in der Zeit zurück gehen, z.B. zur letzten Serverversion, zur funktionierenden Version von vor zwei Wochen, etc.; wichtigstes älteres System: CVS, wichtigstes neueres System: Git; Empfehlung: Git lernen, für eigene kleine Projekte verwenden (wichtiges Werkzeug für Programmierer, geht auch rein lokal, ohne Server) | — |
| Kompilieren und Testen | Code OK, nächster Schritt? – funktioniert der Code? Wie überprüfen? – 1.) Kompiler; 2.) Tests; Bisher: viele einzelne Klassen mit Tests, wie zusammen? – Suite implementieren: Klasse mit Annotation (s. Code); in Eclipse per Wizard; führt alle Tests aus | s. Code: TestSuite |
| Javadoc | Standard-System zur Code-Dokumentation in Java: Javadoc; Package-, Klassen- und Methodendokumentation; Leitprinzip: mindestens public API dokumentieren (d.h. auch: wenig public – wenig Dokumentationsarbeit); Wozu überhaupt Doku im Code? – z.B. beim Editieren, Hinweise warum man X und Y macht; Noch wichtiger als Code-Doku? – Als Benutzer der API: Hilfe, Auto-Completion; /** Kommentar */ statt /* Kommentar */, dazu tags wie @return oder @param; auch für externe HTML-Doku; z.B. in Eclipse generieren |
— |
| Grundproblem | Wir können Tests in Eclipse ausführen, können Javadoc in Eclipse generieren; auf unserem Rechner; reicht das? – was wenn jemand anderes an dem Code arbeiten soll? – müsste z.B. gleiche IDE verwenden, gleiches Setup; das ist nicht gut und nicht realistisch; Verwendung des Code sollte nicht an eine bestimmte IDE gebunden sein; wir wollen ein allgemeines Projekt, das auf jedem Rechner mit Java gebaut und ausgeführt werden kann | — |
| CRISP builds | Der Build-Prozess sollte daher bestimmten Anforderungen entsprechen; der build sollte CRISP sein: Complete (von Grund auf, ohne Interaktion, z.B.? – was runterladen, an einen Ort legen, etc.); Repeatable (wiederholt ausführbar; versioniert wie Code); Informative (Informationen zum Zustand, Erfolge oder Problemen des Builds); Schedulable (automatisch zu bestimmter Zeit ausführbar); Portable (auf verschiedenen Rechnern und verschiedenen Betriebssystemen ausführbar) | — |
| Build-Schritte | Was gehört zu einem vollständigen Build? – Ausgangspunkt: Quelltext, was dann? – z.B. 1.) Kompilieren von Java- zu Class-Dateien; 2.) Testen mit JUnit; 3.) Dokumentation mit Javadoc; 4.) Packen zu Jar; Grundidee: das alles nicht von der IDE, sondern von einem kleinen, spezialisierten Build-Tool machen lassen | — |
| Ant: allgemein | In der Java-Welt sehr verbreitetes Build-Tool: Ant; sehr vielseitig und relativ low-level; hat eingebaut Java-Sachen wie den Kompiler, Javadoc, JUnit, Ausführung; zudem generischere Sachen wie kopieren, zippen, etc.; zudem Erweiterungen wie FindBugs (sehr zu empfehlen, analysiert Code und findet häufige Fehler, gibts auch als Eclipse-Plugin) | — |
| Ant: Verwendung | Ant ist eine XML-basierte Sprache; Grundkonzepte: Properties (sowas wie Konstanten, s. Code) und Targets (sowas wie Methoden); Targets können voneinander abhängen; rufen dann wenn sie selbst aufgerufen werden ihre Abhängigkeiten auf; wie mit Ant die Schritte oben umsetzen? – jeweils als Targets; wie voneinander abhängig? – s. Abb.; Umsetzung s. Code; dabei classpath erstellen; inwiefern low-level? – alle Schritte selbst implementieren |  |
| Maven | Als Alternative zum Ant-Ansatz bei dem man quasi alles selbst konfiguriert (definiere Ort wo Code liegt, kompiliere alle Dateien an dem Ort, lege Ergebnis an anderem Ort ab, baue einen Classpath aus alles Class- und allen Jar-Dateien, etc.) reicht es in der Praxis oft, einer Standard-Konvention zu folgen (z.B. Code, Tests und Bibliotheken an bestimmte Orte zu legen) und alles automatisch vom Framework machen zu lassen; diesen Ansatz verfolgt Maven, das zweite weit verbreitete Build-Tool für Java (lohnt sich anzusehen); aber Ant sehr verbreitet und total vielseitig, auch in Kombination mit Maven, deshalb Fokus Ant heute | — |
| Ausführung | Ant (und auch Maven) lassen sich in Eclipse ausführen; aber was hatten wir für Ziele? – Build sollte unabhängig von der IDE ausführbar sein; deshalb z.B. Konsole: wenn Ant installiert ist, muss man nur im Ordner, in dem die build.xml liegt ant ausführen, und das Default-Target des Skripts wird ausgeführt; was wollten wir noch? – Unabhängigkeit vom eigenen Rechner | — |
| Continuous Integration | Deshalb sogenannte Continuous Integeration Server (z.B. Hudson/Jenkins): eine Applikation auf einem anderen Rechner, Hudson/Jenkins einfach zu konfigurierende Webapplikation, im Grunde nur sagen wo der Source-Code liegt und welches Skript wann ausgeführt werden soll; macht das regelmäßig, verlinkt Testergebnisse, etc.; so kann man mit Ant z.B. auch automatisch Sachen auf seinem Webserver veröffentlichen (z.B. neuester Download, aktuelle Testergebnisse und Dokumentation); wenn man jetzt noch regelmäßig seinen Code committed, hat man eine kontinuierliche Integration (continuous integration) von seinen Änderungen am Code, den passenden Testergebnissen, Dokumentation, und Releases, z.B. als Downloads von Jars | — |
| Fazit | Code, und wie man ihn zusammenpackt; damit im Prinzip durch; nächste Woche Besprechung Aufgabenstellung Hausarbeit | — |