“it works on my machine“ – zeitgemäßes Einrichten der Entwicklungsumgebung

kommentiert 2
gelesen 96

Wenn ich als Entwickler in ein Projekt einsteige, möchte ich sofort mit der Entwicklung beginnen können, ohne zuvor jedes Mal viel Zeit zu investieren, um meine Entwicklungsumgebung aufzusetzen. Wenn ich erst im Laufe des Projektes hinzustoße, möchte ich eine Entwicklungsumgebung mit demselben Stand wie die bereits am Projekt arbeitenden Entwickler – inklusive aller projektspezifischen Einstellungen wie Code Formatierung, Plugins und Erweiterungen.

Stattdessen muss ich mir diesen Stand meist mühsam erarbeiten, Eclipse oder eine andere integrierte Entwicklungsumgebung (IDE) einrichten, alle Einstellungen vornehmen und die jeweiligen Plugins installieren – immer vorausgesetzt, es wurde innerhalb des Projektes eine Dokumentation dieser Prozessschritte angelegt. Das sind lästige, wiederkehrende Aufgaben, die viel Zeit kosten.

Wurde die Entwicklungsumgebung dann eingerichtet, kann es passieren, dass nicht alles wie erwartet funktioniert, getreu dem Spruch, den vermutlich jeder Entwickler kennt: “it works on my machine“. Bei der Suche nach der Ursache, verzweifelt man häufig an verschiedenen Installationen und Versionen von z.B. Plugins und Erweiterungen.

Dieser Beitrag soll wertvolle Tipps liefern, wie man eine zeitgemäße Entwicklungsumgebung – möglichst ohne die beschriebenen Hürden – einrichten kann.

It works on my machine
Bildquelle [1]
Erweiterbarkeit und Anpassungsfähigkeit von Eclipse

Doch warum ist es so aufwendig, die Entwicklungsumgebung einzurichten? Insbesondere die Eclipse IDE hat hier ein Problem, das zugleich eine ihrer entscheidenden Stärken ist: Anpassungsfähigkeit und Erweiterbarkeit. Zum einen ist fast alles über benutzerspezifische Einstellungen personalisierbar, zum anderen gibt es eine vielfältige Plugin-Landschaft, die alle nur denkbaren Entwicklungs-Aufgaben unterstützt, von Versionsverwaltung über Bug-Tracker bis hin zu statischer Codeanalyse [2]. Dadurch lässt sich die IDE so anpassen, dass sie die jeweiligen Projektanforderungen optimal unterstützt.
Diese Vielfalt bringt jedoch auch das Problem mit sich, dass jeder Entwickler im Team diese Anpassungen vornehmen – und sie nachziehen muss, wenn sich im Projektverlauf Änderungen oder Erweiterungen ergeben. Wird im Projektverlauf auf eine neue Eclipse-Version umgestellt, müssen erneut alle Personalisierungen durchgeführt werden.

Einheitliche Entwicklungsumgebung für das Team durch Automatisierung

Warum also nicht das Einrichten der Entwicklungsumgebung automatisieren, um eine einheitliche Umgebung für das gesamte Team bereitzustellen? Die automatisierte Einrichtung führt nicht nur zu einer großen Zeitersparnis, sondern trägt auch dazu bei, die mühsame  Fehlersuche bei unterschiedlichen Versionen und Installationen zu vermeiden. 

 

Für Eclipse gibt es dafür das Open Source Projekt Oomph, ein Eclipse Installer, der seit dem Mars Release bereits in Eclipse integriert ist [3]. Mit Oomph können Profile anhand von individuell angepassten Eclipse-Instanzen festgelegt werden. Das umfasst sowohl installierte Plugins, als auch Einstellungen und Projektspezifikationen wie Repositories und Projekte, die ausgecheckt werden müssen. Die Einrichtung mit Oomph funktioniert plattformneutral, unabhängig davon ob als Betriebssystem Linux oder Windows verwendet wird.

 

Oomph erlaubt es eine einheitliche Entwicklungsumgebung für das Projektteam innerhalb weniger Minuten aufzubauen. Dazu wird eine Product Setup Datei/ Project Setup Datei erstellt, die alle projektspezifischen Einstellungen enthält. Diese kann bei der Installation im Oomph Eclipse Installer ausgewählt werden, um Eclipse mit den vorgenommenen Personalisierungen zu installieren.

Die Product Setup Datei umfasst die Eclipse-Installation inklusive der zu installierenden Plugins und der Art des Starts. Mit dem Preference Recorder können außerdem individuelle Einstellungen in der Setup Datei gespeichert werden, z.B. Zeilennummern und Code-Formatter.

Die Project Setup Datei ermöglicht es darüber hinaus projektspezifische Einstellungen zu konfigurieren, z.B. können Repositories geklont und Projekte daraus importiert werden.

Werden im Laufe des Projektes Änderungen an den benutzerspezifischen Einstellungen gemacht oder Plugins hinzugefügt, können diese in der Oomph Setup Datei gespeichert werden. Dadurch kann die Änderung von einem Entwickler gemacht werden und steht beim nächsten Start der Entwicklungsumgebung auch allen anderen Entwicklern zur Verfügung. Bei der Installation einer neuen Eclipse-Version werden alle personalisierten Änderungen übernommen. Standardmäßig wird mit Oomph sogar immer die neueste Eclipse Version installiert.

 

Fazit

Oomph ist ein gutes Werkzeug, um die Entwicklung von Software zu vereinfachen. Die durch das Tool erreichbare Automatisierung und Reproduzierbarkeit spart wertvolle Zeit und ermöglicht es Entwicklern, sich auf das Wesentliche zu konzentrieren. Außerdem hilft der Eclipse Installer sicherzustellen, dass alle Teammitglieder mit denselben Versionen arbeiten.

Noch einen Schritt weiter geht die Automatisierung mit dem Open Source Werkzeug Vagrant: Anstatt nur das Einrichten der Entwicklungsumgebung zu automatisieren, werden ganze virtuelle Maschinen inklusive Anwendungen erstellt – automatisiert und reproduzierbar. Dies geschieht auf Basis einer Skriptdatei, mit der sich die VM jederzeit reproduzieren lässt. [4]


Quellen: 
[1]http://simply-the-test.blogspot.de/2010/05/it-works-on-my-machine.html
[2]https://jaxenter.de/eclipse-insights-ein-fertig-konfiguriertes-eclipse-27523
[3]https://www.heise.de/developer/meldung/Jaehrliches-Release-Eclipse-IDE-steht-in-Version-4-5-bereit-2725321.html
[4]https://www.heise.de/developer/artikel/Vagrant-und-Docker-Eine-zeitgemaesse-Entwicklungsumgebung-2411620.html


Mehr zu moderner Softwareentwicklung erfahren Sie hier

 

Zurück zur Übersicht

2 Kommentare zu ““it works on my machine“ – zeitgemäßes Einrichten der Entwicklungsumgebung

  1. Hallo JustAnotherDev,

    wir haben eine Oomph Expertengruppe, die Templates für die Setup Dateien entwickelt. Diese Templates werden dann innerhalb des jeweiligen Projektes projektspezifisch angepasst. Die Entscheidung, wer diese Templates anpasst, wird innerhalb des jeweiligen Projektes getroffen, ggf. mit Rückfragen an die Expertengruppe.

  2. Oomph ist definitiv ein guter Ansatz, jedoch auch sehr kompliziert im Setup. Wie geht ihr damit um? Kümmert sich ein Experte im das Setup oder darf da jeder Entwickler ran?

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*Pflichtfelder

*