Eclipse und Mylyn

Mylyn- und Review-Systeme

Wie bereits weiter oben erwähnt, sind bei uns im Unternehmen leider auch zwei unterschiedliche Review-Systeme im Einsatz. Zum einen wäre das Gerrit und zum anderen Atlassian Crucible. Beide haben unterschiedliche Ansätze. Während Gerrit nur den Pre-Commit Review unterstützt, kann man mit Crucible auch Post-Commit Reviews machen.

Mylyn hat auch für Review-Systeme ein eigenes Subprojekt namens Mylyn Reviews. Gerrit wird dabei optimal unterstützt. Mylyn Reviews bietet keine neue View, sondern verwendet die Taskliste von Mylyn. Als Task fungiert hier ein Change in Gerrit (Abb. 4). Typischerweise entspricht ein Change in Gerrit einem Task in einem Task-Tracking-System wie JIRA. In dem zugehörigen Editor finden Sie alle Details des Change. Dazu gehören typische Attribute wie Autor, Beschreibung, Projekt und Branch. Zusätzlich werden noch alle Patchsets angezeigt, die dem Change zugeordnet werden können. Als Patchsets werden die einzelnen Pushes für einen Change bezeichnet, die nötig sind, weil die erste Version des Change noch nicht zufriedenstellend war. Atlassian hat seinen Support für Crucible innerhalb einer IDE vor etwa einem halben Jahr aufgekündigt. Hier gibt es leider keine direkte Integration mehr.

Abb. 4: Gerrit-Editor
Mylyn und Sonar

Sonar sammelt Daten, die die Qualität eines Projekts beschreiben, und bereitet sie auf. Dabei kann Sonar Trends aufzeigen und man ist in der Lage, die Qualitätsveränderungen zwischen Commits zu bestimmen. Einen großen Teil der Sonar-Daten nehmen die so genannten Code Violations ein. Das sind Dinge, die Tools wie Checkstyle, FindBugs und PMD bemängeln. Sonar bietet bei den Violations eine detaillierte Codeansicht an, an die man Kommentare hängen kann, also auch eine Art Review. Diese Kommentare kann man über die Sonar-Mylyn-Integration in die Taskliste integrieren. Der andere Teil der Sonar-Integration kommt ohne Mylyn aus. Es gibt einige Views, die relevante Aspekte (Violations, Hotspots für Komplexitäten) visualisieren und von denen aus Sie direkt an die richtige Stelle im Quellcode navigieren können.

Und nun alles zusammen

Nachdem man sich die entsprechenden Plug-ins in Eclipse installiert hat, kann es losgehen. Die einzelnen Plug-ins müssen konfiguriert werden. Typischerweise sind das die Zugangsdaten und mindestens eine Query, um die Tasks abzurufen. Mylyn hat eine eigene Perspektive mit dem Namen Planning. Sie ist danach auch gut gefüllt mit den einzelnen Views. Und damit komme ich auch direkt zu dem Knackpunkt des Ganzen: Der Entwickler kann jetzt mit den webbasierten Tools arbeiten, ohne Eclipse verlassen zu müssen. Die einzelnen Integrationen machen ihre Aufgaben auch hervorragend. Aber untereinander gibt es keine Möglichkeit. Zum Beispiel ist es nicht möglich, in dem Taskeditor von JIRA die entsprechenden Builds dazu anzusehen. Ein anderes Szenario ist es, dass man sich bei einem fehlerhaften Build den entsprechenden Task dazu ansehen möchte. Der direkte Weg dazu existiert ebenfalls nicht. An dieser Stelle ist noch viel zu tun. Auch wäre es schön, wenn die zusätzlichen Views wegfallen würden und man alles in der Taskliste hätte. Dadurch wäre der Überblick etwas besser, da man während der täglichen Arbeit selten durch die ganzen Views durchschaltet. Trotz allem lohnt sich die Mühe aber, die ganzen Integrationen zu installieren und zu konfigurieren. Alleine das kleine Feature, mit dem Mylyn sich Änderungen für einen aktivierten Task merkt und eine Commit-Message vorschlägt, erleichtert einem die Arbeit sehr.

Ein Open-Source-Szenario

Nun verlassen wir Bob und Peter. Ich möchte Ihnen noch zwei Szenarien vorstellen, die sich mit Mylyn und Eclipse sehr gut verwenden lassen. Jeweils ein Open-Source- und ein Enterprise-Szenario. Das erste Szenario eignet sich für die Entwicklung eines Open-Source-Projekts, und es sind nur Tools dabei, die keine Lizenzkosten verursachen. Die Basis dieses Szenarios ist GitHub. Die Onlineplattform bietet öffentliche Repositories ohne Einschränkung der Anzahl der Mitarbeiter. Es bietet ein Wiki und einen sehr einfachen Bug Tracker. Er reicht für die einfachsten Anwendungsfälle, will man aber die Projektorganisation darüber machen, benötigt man etwas mehr. Dazu wird hier der Pivotal Tracker [12] verwendet, ein agiles Projektmanagementtool, das für öffentliche Projekte keinerlei Einschränkungen hat. Das Kernkonzept von Pivotal Tracker basiert auf einem Backlog und auf Stories. Damit ist es konzeptionell stark an Scrum angelehnt. Sie können zu einer Story auch Tasks anlegen, aber das sind einfache To-do-Listen ohne weitere Funktionalität. Der Pivotal Tracker lässt sich sehr gut mit GitHub integrieren, sodass ein Push in GitHub automatisch einen Kommentar auf der entsprechenden Story erzeugt. Für die Continuous Integration können Sie Jenkins@Cloud [13] von Cloud Bees verwenden.

Für die Integration in Eclipse ist auch gesorgt. Mit dem aktuellsten Egit-Plug-in gibt es Unterstützung für GitHub. Sie können einfach Ihre Repositories aus GitHub importieren (Abb. 5). Für den Pivotal Tracker gibt es seit diesem Jahr auch eine Mylyn-Integration, die ähnlich der für JIRA oder Bugzilla funktioniert. Und über die Integration von Jenkins haben Bob und Peter ja schon geschrieben.

Abb. 5: Import eines GitHub Repositorys
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.