Versionsverwaltung

„Eine Versionsverwaltung ist ein System, das zur Erfassung von Änderungen an Dokumenten oder Dateien verwendet wird. Alle Versionen werden in einem Archiv mit Zeitstempel und Benutzerkennung gesichert und können später wiederhergestellt werden. Versionsverwaltungssysteme werden typischerweise in der Softwareentwicklung eingesetzt um Quelltexte zu verwalten. Versionsverwaltung kommt auch bei Büroanwendungen oder Content-Management-Systemen zum Einsatz.“

Quelle: Wikipedia

Die RBG/ISP stellt seit dem August 2011 eine Projektverwaltungs- Software in der Beta Phase zur Verfügung. Sie hört auf den Namen Chiliproject (nicht Teil des Wikis) und ist ein Fork von Redmine (nicht Teil des Wikis).

Jede Projektleitung hat die Möglichkeit, verschiedene Module einzusetzen:

• Tickets
• Gantt Diagramme
• News
• Einblick in das Projektarchiv mit Diffvorschau
• Wiki
• Dateiverwaltung
• …

Alle Studierende mit einem aktiven RBG/ISP Account können sich an der Software anmelden und Unterprojekte erzeugen. Der Account ist auch notwendig, wenn sich mehrere Personen an einem Projekt von Studierenden beteiligen wollen.

Beim erstmaligen Einloggen wird automatisch ein Projekt mit dem RBG/ISP Loginnamen erzeugt. Dieses „Projekt“ darf nicht verwendet werden (z.B. umbennen, Rollen verändern etc.), da es der Zuordnung der nachfolgenden (Unter-)Projekte dient. Das bedeutet, nach dem Login muss ein Unterprojekt angelegt werden, welches die Kennung des Hauptprojektes (also vom Loginnamen abgeleitet)enthält. Siehe dazu weiter unten.

Ein kurzer Überblick, wie die Software zu verwenden ist:

Um es in irgendeiner Weise nutzen zu können - also als Unterstützung an einem Projekt, oder um selbst ein Projekt zu erstellen - begibt man sich auf die Webseite und loggt sich oben Rechts ein:

• Es erscheint das Fenster zum anmelden:

• Die Daten müssen vervollständigt werden. Vor- und Nachname sollten bereits ausgefüllt sein, die E-Mail Adresse muss separat nachgetragen werden:

• Danach können noch allgemeine Optionen konfiguriert werden:

Beim erstmaligen Anmelden wird automatisch ein Projekt erzeugt, bestehend aus den Vor- und Nachnamen, bzw. dem Loginaccount. Dies ist notwendig um die passenden Rechte zu erhalten, ein Projekt erzeugen zu dürfen.

• Um ein Unterprojekt zu erstellen, oben rechts z.B. auf das automatisch erstellte Projekt gehen:

• Im Projekt selbst kann nun das Unterprojekt erstellt werden:

• Es erscheint eine Konfigurations- Maske, die entsprechend ausgefüllt werden muss:

Wichtig: Der vordere Teil der Projekt Kennung muss bestehen bleiben, andernfalls wird die Projekterzeugung verweigert.

Wichtig: Beim Abwählen nicht benötigter Module muss Projektarchiv aktiviert bleiben, da ansonsten die SVN/Git Funktion nicht bereitsteht.

Der Einfachheit sollte der zweite Teil der Kennung gleich dem Projekttitel sein (ohne Leerzeichen).

Als SCM lassen sich sowohl SVN auswählen, als auch Git. Wer sich unsicher ist, wählt SVN, da dies sehr weit verbreitet ist und auch von verschiedenen Editoren unterstützt wird.

Der Schalter Öffentlich bewirkt, dass zum einen das Projekt von allen eingesehen, als auch von allen ausgecheckt werden kann. Ist dies nicht der Fall, können nur zugelassene Mitglieder darauf zugreifen.

• Am Ende steht das fertige Projekt, welches nun genutzt werden kann:

Hier die ersten Schritte die Notwendig sind, ein SVN Repository bereitzustellen. Hier mit dem Beispiel Projekt Toscana und dem User Testds:

$ svn co https://testds@svn.rbg.informatik.tu-darmstadt.de/svn/testds-toscana
$ cd testds-toscana
$ echo "Test" > first_file.txt
$ svn add first_file
$ svn ci -m "Erster Eintrag"

Es sind als Zertifikate die der TU-Darmstadt im Einsatz. Die Wurzelzertifikate sind hier zu finden.

Hat dies funktioniert, kann im Chiliproject unter Projektarchiv die Veränderung eingesehen werden.

SSL Probleme: Leider prüft SVN nicht die gesamte Zertifikatskette, auch wenn sie vom Webserver ausgeliefert wird. Daher hilft oftmals nur eine Anpassung in der Server Konfguration von SVN:

echo "ssl-ignore-unknown-ca = true" >> ~/.subversion/servers

Für diejenigen, die Git verwenden, sind etwas andere Schritte notwendig:

$ git clone https://loginname@git.rbg.informatik.tu-darmstadt.de/testds-toscana.git
$ cd testds-toscana
$ echo "Test" > first_file.txt
$ git add first_file
$ git commit -am "Erste Datei"
$ git push origin master

Wer Probleme mit dem SSL Zertifikat hat, sollte vorher

export GIT_SSL_NO_VERIFY=1

eintippen. Dies sorgt dafür, dass Git nicht das Zertifikat überprüft. Wer dies dennoch möchte, muss die Stammzertifikate der TU-Darmstadt installieren. Diese sind hier zu finden.

Nun lassen sich die ersten Änderungen unter dem Projektarchiv im Chiliprojekt wiederfinden.

Wichtig: Der*Die Initiator*in des Projekts darf nicht auf die Idee kommen, sich selbst zu Entwickler*in zu „degradieren“, da er*sie sonst keinen vollständigen Zugriff mehr auf die Projekte hat. Für den Fall, dass es dennoch passiert ist, bitte eine Mail an sysop@isp... mit dem Betreff: SCM

Um dem eigenen Projekt Mitglieder hinzuzufügen, im jeweiligen Projekt auf die Projekt- Konfiguration gehen (siehe Bild, 1. Pfeil), dann auf Mitglieder (Pfeil 2) und auf der rechten Seite über die Suche die passenden Mitglieder und deren Rolle (es reicht Entwickler*in für die anderen Mitglieder → nicht sich selbst zu Entwickler*in machen) auswählen (Pfeil 3)

Bei Statusänderungen, z.B ein neues Ticket, wird eine E-Mail versendet. Dies lässt sich in den Projekteinstellungen anpassen. Des weiteren ist es auch möglich auf Tickets per E-Mail zu antworten. Dazu darf der Betreff der Ticket E-Mail nicht angefasst werden, da sonst die Zuordnung zum Projekt verloren geht und die E-Mail gelöscht wird.

1. Als Studierende: Projekte können nur von der RBG/ISP auf Anfrage gelöscht werden
2. Automatisch: Ist ein*e Studierende*r nicht mehr beim HRZ gemeldet, so werden deren Projekte ebenfalls gelöscht. Das hat auch zur Folge, dass Gruppenmitglieder keinen Zugriff mehr haben

Als Orientierungshilfe ist es für die RBG/ISP erforderlich, die zu löschenden Projekte umzubennen nach <loginname-projektname>_zuloeschen.

Das Umbenennen wirkt sich allerdings nur auf den Projekttitel aus, nicht auf die hochgeladenen Dateien und angelegte Repositories, sodass ein erneutes anlegen mit selben Namen fehlschlägt.

Für den Fall, dass Jenkins und Co. automatisch das SVN bzw. Git abrufen können sollen, gibt es den User „checkoutuser“ und die Rolle „checkout“. Diese Rolle hat lediglich Rechte einen „Checkout“ durchzuführen, jedoch keinen „Commit“.

Das Kennwort muss bei der RBG/ISP angefragt werden.

• Wer Hilfe zu Redmine/Chiliprojct sucht, wir hier fündig:
  • https://www.chiliproject.org
  • http://www.redmine.org

• Hilfe zu SVN:
  • https://www.bsdwiki.de/Subversion

• Hilfe zu Git:
  • http://rogerdudler.github.com/git-guide/
  • Git vs. SVN http://git.or.cz/course/svn.html
  • http://pkqs.net/~sbeyer/tmp/pre-git-clt09.pdf

Die RBG/ISP sichert stündlich auf Dateiebene die SVN und Git Projekte sowie hochgeladene Dateien. Dabei wird jedoch keine Rücksicht auf die SVN spezifischen Datenbanken genommen. Zwei mal pro Tag wird eine DB Backup Sicherung von Chiliproject erstellt.

Doch wie so immer in der IT, schadet es auch nichts, selbst vom eigenen Projekt entsprechende Backups zu erstellen.

Die Projekte laufen auf einem separaten Server und tasten somit den Plattenquota nicht an. Doch wird darauf geachtet den Festplattenplatz nicht durch hoch geladene Dateien zu füllen. Daher bitte bei Bildern etc. auf die Auflösung und Größe zu achten.

• Der*Die Projekt-Erzeuger*in macht sich zu Entwickler*in
  • Was passiert: Gibt sich der*die Projekt-Erzeuger*in die Rolle des Entwicklers, so werden ihm*ihr seine*ihre Manager*in Funktionen entzogen, was dazu führt, dass derjenige keine Management Rechte mehr besitzt und diese erst von der RBG/ISP wieder zugeordnet werden müssen.
• Haupt- Projekt wurde umbenannt
  • Was passiert: Hat der*die Projekt-Erzeuger*in den Button für das Umbennen des Projektes gefunden, und nutzt diesen, führt dies dazu, dass das Projekt ihm*ihr komplett entzogen wird. Da beim Erzeugen des Projektes diverse Datenbank und Dateisystem Einträge erstellt, können diese nicht einem*r Studierenden zugeordnert werden. Daher wird das Projekt von der RBG/ISP gelöscht und dem eigentlichen Initiator*in neu erstellt und zugeordnet.
    • Einzige Ausnahme gilt nur dann, wenn das Projekt gelöscht werden soll.

Sollten technische Fragen od. Probleme auftreten, bitte diese an sysop@rbg... richten.