Irgendwann im Leben eines Software-Entwicklers kommt der Punkt, wo man auch privat seine Code-Sammlung einerseits versionieren möchte, andererseits auch seine gefundenen Issues protokollieren möchte. Manche Projekte wollen dann auch in einer kleinen Gruppe bzw. im Team gelöst werden. Beispielsweise bei Gruppenarbeiten während der Schulzeit bzw. eines Studiums.
Zur Versionierung gibt es viele Möglichkeiten. Die bekanntesten stellen wohl Subversion (SVN) oder Git dar. Beide haben Ihre Vor- und Nachteile. Darüber hinaus gibt es für OpenSource-Projekte tolle Möglichkeiten seine Projekte gratis öffentlich ins Netz zu stellen (z.B. GitHub). Für private Projekte wird man dann allerdings meistens zur Kasse gebeten. Nachdem ich nicht all meine privaten Projekte öffentlich ins Internet stellen möchte, suchte ich nach einer (kostenlosen) Lösung, welche genau dieses Problem angeht.
Nachdem an meinen privaten Projekten nicht über den gesamten Globus verteilt Personen daran arbeiten und der „Server“ immer verfügbar ist, fiel die Entscheidung zur Versionierung auf Subversion. Anschließend suchte ich nach einer Issue-Tracking-Lösung, welche zusätzlich automatisch die Commits mit den Issues verknüpfen kann. Das ganze sollte auch noch eine halbwegs moderne und ansprechende Web-Oberfläche bieten. Letztendlich fiel die Entscheidung auf OpenProject. Es handelt sich dabei um ein doch recht ausgewachsenes Projektmanagement-Tool, welches zusätzlich mittels Plugins erweitert werden kann.
Natürlich soll die Projektverwaltung nicht lokal laufen und habe mich daher für eine virtuelle Maschine mit Ubuntu Server 14.04 LTS entschieden.
Installation
Nachdem OpenProject eine frische Installation empfiehlt, vor allem ohne Web-Management-Software à la Plesk, setzte ich eine eigene neue Instanz auf, welche zukünftig nur für OpenProject dienen wird. D.h. während des Installationsprozesses, wo Ubuntu Server verschiedene Software zum Installieren anbietet, sollten wir einmal nichts auswählen. Außer vl. einen SSH-Server, da hiermit dann Copy-Paste leichter fällt. Ersichtlich in der folgenden Abbildung:
Sobald die virtuelle Maschine eingerichtet ist, kann bereits die Installation mit den folgenden Commands beginnen:
wget -qO - https://deb.packager.io/key | sudo apt-key add -
echo "deb https://deb.packager.io/gh/finnlabs/pkgr-openproject-community trusty stable/4.1" | sudo tee /etc/apt/sources.list.d/pkgr-openproject-community.list
sudo apt-get update
sudo apt-get install openproject-ce
Ich habe mich für die Community-Edition entschieden, da diese zusätzliche, nützliche Plugins anbietet. Eine Übersicht über die verschiedenen Versionen findet ihr hier.
Es kann sein, dass die Installation nicht auf Anhieb klappt. Bei mir trat dieses Problem mit Version 4.1 reproduzierbar auf. Dann probiert es mit
sudo apt-get install openproject-ce --fix-missing
Das dauert dann zwar ziemlich lange (~10 Minuten), um die 106 MB herunterzuladen, weil dann, zumindest bei mir, nur noch mit ~100KB/s heruntergeladen wurde. Darüber hinaus verharrt der Status bei „1% [Wird verarbeitet]“, bis er fertig ist. Die Installation klappt aber. Geduld vorausgesetzt. ;) Wenn jemand sichergehen möchte, kann man sich den Download beispielsweise auch mit dem Tool „tcptrack“ in einem eigenen PuTTY-Session-Window ansehen (muss dann natürlich aber vor openproject-ce installiert werden):
sudo apt-get install tcptrack
sudo tcptrack -r 2 -i eth0
Nach der Installation folgt die Konfiguration, welche mittels
sudo openproject-ce configure
eingeleitet wird. Die einzelnen Konfigurationsschritte sind nicht wirklich gut in der Installationsanleitung auf OpenProject.org erläutert, weswegen ich hier eine ausführlichere Anleitung geben möchte.
Gleich am Anfang wird danach gefragt, ob wir uns selbst um die MySQL DB kümmern wollen, oder ob wir das dem Installer überlassen. Nachdem alles eine komplett frische Installation ist können wir dies, ohne große Bedenken, dem Installer überlassen und wählen die zweite Option:
Gleiches Spiel mit dem Apache2 Server:
Nachdem es sich um eine mehr oder weniger lokale Maschine handelt, kann der Default-Hostname gewählt werden:
Außerdem benötigen wir aus dem selben Grund auch kein SSL. Sollte dennoch SSL zur Anwendung kommen, so muss dafür noch ein (selbstsigniertes) Zertifikat am Server hinterlegt werden:
Beim nächsten Schirm ist der Pfad zum SVN-Repository wichtig. Diesen darf man im Anschluss nicht vergessen, um einerseits SVN zu konfigurieren, andererseits auch um entsprechende Repositories darin anzulegen:
Bei der E-Mail-Konfiguration kann sendmail verwendet werden und anschließend eine E-Mail-Adresse, von welcher aus E-Mails gesendet werden sollen:
Anschließend muss noch Postfix konfiguriert werden. Hier kann einfach „Internet-Site“ ausgewählt werden:
Beim System-Name ist es wichtig einen Namen zu wählen, für welchen ihr auch berechtigt seid. In meinem Fall wäre das beispielsweise „zubasoft.at“:
Einrichten
Damit ist die Installation abgeschlossen. Nun kann direkt über die IP-Adresse des virtuellen Servers (ifconfig) auf das Web-Interface zugegriffen werden. Default-User/Passwort lautet admin/admin. Der Schirm wird in etwa so aussehen:
Nach dem Login müsst ihr gleich einmal das Default-Passwort für den Admin-User ändern.
Wer übrigens die Sprache gerne auf Deutsch ändern möchte, kann dies über den Menüpunkt „Modules“ –> „Administration“ machen. Hier können außerdem Default-Werte automatisiert angelegt werden. Aber dazu später. Um auf Deutsch umzustellen geht ihr hier nun links im Menü auf „Settings“ und auf die Registerkarte „Display“. Hier könnt ihr die gewünschten Sprachen auswählen, welche zur Verfügung stehen sollen:
Anschließend könnt ihr im Menü auf „User“ gehen, den „admin“-User auswählen und die Sprache auf „Deutsch“ umstellen. Ihr müsst hierbei auch vor dem Speichern weiter unten das Passwort 2x eingeben, da es sich um Pflichtfelder handelt.
Nach diesem Schritt empfiehlt es sich die Datenbank mit Default-Einstellungen zu bestücken. Dafür gehen wir nochmals zurück auf den Menüeintrag „Projekte“. Nun können die Default-Werte auch auf Deutsch angelegt werden. Klickt einfach auf den Button „Standard-Konfiguration laden“:
Im Administrations-Menü sind viele verschiedene Einstellungen möglich. Alle an dieser Stelle zu erklären, würde den Rahmen sprengen. Es ist nur sehr wichtig, diese Seite zu kennen, da hier einerseits die Rollen- und Rechte verwaltet werden können. Andererseits aber auch viele Default-Einstellungen getätigt werden können, wie beispielsweise die Arbeitspaket-Typen, Arbeitspaket-Status usw. Unter dem Menüpunkt „Konfiguration“ auf der Registerkarte „Projektarchive“ können dann auch noch Schlüsselwörter für SVN/Git definiert werden, sodass zwischen dem Commit und dem Arbeitspaket eine Referenz hergestellt werden kann. Aber dazu später mehr.
Kommen wir nun zurück zum eigentlichen Thema: Wir wollen ein Projekt anlegen. Das könnt ihr über den Menüpunkt „Projekte“ –> „Alle Projekte anzeigen“. Anschließend kann über den Button „New Project“ ein neues Projekt angelegt werden:
Beim Anlegen des Projekts vergebt ihr einen Namen, als auch eine eindeutige Kennung. Die Kennung entspricht dann auch dem Unterverzeichnis im Subversion-Verzeichnis. Darüber hinaus könnt ihr aus einer Liste von Modulen auswählen, welche ihr einsetzen möchtet. Ich habe es einmal bei den Default-Einstellungen belassen. Bei den Typen, gibt es einige vordefinierte, wie Beispielsweise „Task, Milestone, Bug, Feature“. Typen dienen um Issues, bzw. in OpenProject werden diese „Work Packages“ bzw. „Arbeitspakete“ genannt, besser zu Kategorisieren.
Dieses können wir wieder im Menü über „Projekte“ auswählen und gehen anschließend im Menü Links auf „Arbeitspakete“. Hier kann über den „Plus-Button“ ein neues Arbeitspaket mit einem bestimmten Typ (welche wir bei der Projekterstellung ausgewählt haben) anlegen:
Arbeitspakete können auch miteinander verknüpft werden. Dafür legen wir gleich ein Arbeitspaket mit dem Typ „Milestone“ an. Anschließend kann über „Arbeitspakethierarchie“ eine richtige Hierarchie erstellt werden, oder aber es können über „zugehörige Arbeitspakete“ diese einfach miteinander verknüpft werden:
Was ist nun der Unterschied? Bei der Arbeitspaket-Hierarchie können Subtask, also Unter-Aufgaben, definiert werden. Diese Hierarchie wird auch in der Übersicht abgebildet.
Bei den zugehörigen Arbeitspakete kann die Verknüpfungsart definiert werden. Zur Auswahl stehen:
- Beziehung mit: Ein Link mit einem anderen Arbeitspaket, obwohl diese nicht in der selben Arbeitspaket-Hierarchie abgebildet sein müssen.
- Duplikat: Dient dazu anzuzeigen, dass es sich hierbei um ein Duplikat handelt. Diese Option ist nützlich, wenn z.B. ein Arbeitspaket zweimal vorkommen muss. Beispielsweise in einem privaten und einem öffentlichen Projekt.
- Blockiert: Definiert ob ein Arbeitspaket eine blockierende Wirkung auf ein anderes Arbeitspaket hat. Solange das blockierende Arbeitspaket nicht einen „geschlossenen“ Status hat, kann auch das andere Arbeitspaket nicht geschlossen werden.
- Vorgänger/Folgt: Ein Nachfolger kann nicht ein früheres Startdatum haben, als sein Vorgänger. Es kann auch eine Pufferzeit definiert werden. Z.B.: Der Nachfolger darf erst 5 Tage nach dem Vorgänger gestartet werden.
Nachdem nun die ersten Arbeitspakete definiert wurden, können wir uns dem Thema Subversion und der Verknüpfung mit OpenProject widmen.
Subversion
Sollte man noch nicht all zu viel Erfahrung mit Subversion haben, so empfiehlt es sich das freie Buch über Subversion zu Gemüte zu führen. Es ist meiner Meinung nach eines der besten Open Books, welche es als Anleitungen im Internet gibt. Aber zurück zum eigentlichen Thema:
Nachdem ich mich länger darüber geärgert habe, warum manches Mal bei der Projekt-Erstellung das Subversion-Directory direkt angelegt wurde, und manches mal nicht, machte ich mich im Quellcode auf die Suche, wie das in OpenProject abläuft. Damit euch diese „Fehler-Suche“ erspart bleibt, will ich dies hier kurz näher erläutern, nachdem ich auf der Homepage von OpenProject so gut wie nichts zu den Repositories gefunden habe:
Das Subversion-Directory wird asynchron, erst nach etwa 10 Minuten, automatisch durch einen Cron-Job angelegt. Wann genau der Job läuft, kann leicht mit folgendem Befehl ausgegeben werden:
zgrep -i "create-svn" /var/log/syslog*
Den dafür verantwortlichen Job findet ihr unter „/etc/cron.d/“ und hat den Namen „openproject-create-svn-repositories“. Dieser Job ruft anschließend das Script „/opt/${APP_NAME}/packaging/scripts/create-svn-repositories“ auf. Wobei $APP_NAME den Wert „openproject“ hat. Wenn man sich den Quelltext herunterlädt führt das Ruby-Script „reposman.rb“ im Verzeichnis „/extra/svn/“ den eigentlichen Command durch (svnadmin create).
Lange Rede, kurzer Sinn: Wartet 10 Minuten und alles ist gut. Ihr solltet dann in etwa folgendes in der Projekt-Konfiguration auf der Registerkarte „Projektarchiv“ sehen:
Nach diesem kurzen Ausflug in die Eingeweide von OpenProject kommen wir nun zum nächsten Schritt: Dem Aufbau des Projektarchivs. Es haben sich empfohlene Standards etabliert und diesen möchte ich ebenfalls folgen. Daher geht es nun darum die entsprechenden Verzeichnisse „trunk“, „branches“ als auch „tags“ im SVN-Projektarchiv anzulegen. Das macht ihr am besten am Server mit folgendem Command (Pfade sind entsprechend zu adaptieren):
sudo svn mkdir file:///var/db/openproject-ce/svn/testprojekt123/trunk -m "add parents"
sudo svn mkdir file:///var/db/openproject-ce/svn/testprojekt123/branches -m "add parents"
sudo svn mkdir file:///var/db/openproject-ce/svn/testprojekt123/tags -m "add parents"
Das war es dann auch schon wieder. Jetzt können wir mit einer IDE der Wahl entsprechend das Projekt auschecken. Um sich als User zu authorisieren wird der gleiche User verwendet, mit welchem man sich auf der OpenProject-Web-Oberfläche anmeldet. In Netbeans funktioniert das beispielsweise wie folgt:
Im Menü auf „Team –> Subversion –> Checkout“ gehen. Die HTTP-Adresse besteht aus der IP-Adresse des virtuellen Servers mit dem Unterverzeichnis „svn“ und anschließend der Projektkennung. In meinem Beispiel also anschließend:
http://192.168.100.101/svn/testprojekt123
Als User verwende ich gleich den admin-User.
Falls ihr die Meldung bekommt „Could not open the requested SVN filesystem“, hilft es den „www-data“-User der „openproject“-Gruppe zuzuweisen, da OpenProject alle Ordner mit diesem User bzw. auch der gleichnamigen Gruppe anlegt. Und anschließend den Apache-Server neuzustarten. Das stellt ihr wie folgt an:
sudo usermod -a -G openproject www-data
sudo chmod g+w /var/db/openproject-ce/svn
sudo chmod g+s /var/db/openproject-ce/svn
sudo /etc/init.d/apache2 restart
Anschließend sollte das Problem verschwunden sein. Ansonsten sollte ein Neustart vom Server helfen. Ihr könnt nun das trunk-Verzeichnis auschecken, den entsprechenden Ordner wählen, wo ihr das Netbeans-Projekt verwalten wollt, und anschließend auf den Button „Finish“ klicken:
Nachdem der Ordner leer ist, bietet euch Netbeans auch gleich an ein neues Projekt anzulegen, was ihr am besten auch gleich macht:
Ich habe ein einfaches PHP-Projekt angelegt, welches ich auch gleich Commite, um euch zu zeigen, wie ihr eine Referenz zu euren Arbeitspaketen schaffen könnt:
Bei der Commit-Message gebt ihr einfach das Keyword „refs“ ein, gefolgt von der Arbeitspaket-Nummer. Anschließend folgt die normale Commit-Message:
Anschließend ist dies im entsprechenden Arbeitspaket ersichtlich:
Fazit
OpenProject ist ein gutes Tool um seine Projekte mit Subversion zu verwalten. Die Einrichtung kann sich allerdings durchaus als schwierig erweisen. Oft sind tiefergreifende Linux-Kenntnisse erforderlich bzw. muss nach bestimmten Dingen einfach gegoogelt werden. Die Installation und Konfiguration ist schlichtweg nicht ganz selbsterklärend. Vor allem, wenn Dinge nicht wie gewünscht funktionieren. Die Konkurrenz wie „Trac Open Source Project“ oder „Redmine“ gestalten sich aber auch nicht wirklich benutzerfreundlicher. Die Dokumentation ist auf jeden Fall noch ausbaufähig.
Alles im allen bin ich jedoch sehr zufrieden mit dem Tool. Wenn alles erst einmal läuft, dann läuft es sehr zuverlässig und zufriedenstellend. :)
Ich hoffe ich konnte euch mit dem Artikel eine nützliche Hilfestellung geben.
