Warum eigentlich Source Control Management?
Bei jeder Art der Softwareentwicklung sollte ein SCM, auch bekannt als Versionierungsverwaltung / -software, im Hintergrund benutzt werden. Gerade bei verteilten Teams kann eine parallele Zusammenarbeit am gleichen Code ohne eine Hilfe im Hintergrund sonst sehr chaotisch und zeitraubend ablaufen. Wird an der selben Datei gearbeitet, passiert es ohne Software öfter mal, das Änderungen des einen Kollegen durch den anderen überschrieben werden – ärgerlich und unnötig!
Änderungen nachvollziehen & rückgängig machen (können)
Ein entscheidender Vorteil ist bei der Quellcodeverwaltung aber auch die Nachvollziehbarkeit von Änderungen (Wer hat was, wann verändert) und die Möglichkeit diese im Handumdrehen rückgängig zu machen. Viele Probleme bei einem händischen Zusammenführen und notieren von Änderungen werden so komplett hinfällig.
Git /GitHUB
Das SCM Tool unserer Wahl ist GIT. Modern, vielseitige Funktionen und (inzwischen) auch in alle entscheidenden Tools integriert (Eclipse und Trac in unserem Fall). Und seitdem es GitHUB gibt, in unseren Augen auch die Zukunft. Für Open Source Projekte ist Git Hub sicherlich die erste Wahl, da es kostenlos ist und sehr gute Kolaborations-Funktionen. Für closed source Entwicklungen, wie wir sie auch haben, kommt Github allerdings aus Kostengründen nicht in Frage, da man mit wenig Aufwand alle Funktionen von Github auch auf einem eigenen dedizierten Server bereit stellen kann.
Installation von Git, Trac und mod_wsgi auf Debian Sqeeze
Wie man nun auf einem Debian Squeeze Web-Server, der mit ISPConfig betrieben wird GIT als SCM, Trac als Weboberfläche für das Projektmanagement und als Bugtracker mit Hilfe von mod_wsgi einrichtet, soll im Folgenden beschrieben werden.
Grundvoraussetzungen Server
- Der Server ist installiert und konfiguriert (für ISPConfig am besten nach folgender Anleitung: HowToForge – Der perfekte Server – Debian Lenny oder HowToForge – Der perfekte Server – Debian Squeeze mit Bind und Courier )
- Zugriff auf den user Root per SSH ist vorhanden und möglich
- Python ist in der Version 2.5 oder 2.6 installiert (wir gehen von 2.6 aus)
-
apt-get install python
-
- Zusätzlich zu der Anleitung ist “libapache2-mod-wsgi” istalliert
-
apt-get install libapache2-mod-wsgi
-
- ISPConfig ist installiert und eingerichtet
- Eine “Site” wurde bereits im ISPConfig eingerichtet. Z.b. bugtracker.DOMAIN.TLD oder scm.DOMAIN.TLD (Ich gehe hier im Beispiel einfach mal von scm.bit-dynamics.de aus)
- Für die Site wurde ein “Shellbenutzer” angelegt z.B. “trac” -> “kundenname_trac” wäre dann der User Name
Wir gehen in dieser Anleitung von einem aktuellen Debian Squeeze aus. Dort ist es mit den Grundvorrausetzungen (Python, Git) besser bestellt und Lenny sollte man so oder so nicht mehr aufsetzen. Grundsätzlich sollte man aber die Git / Trac Konfiguration gleich durchführen können, wenn bei den Voraussetzungen alles passt. D.h. insbesondere Python in der richtigen Version installiert, mod_wsgi in der aktuell Version 3.3
Installation und Einrichtung von GIT
- Installation von git-core aus den Debian Repositories (aktuell liegt dort für Debian Lenny 1.5.6.5, für Debian Squeeze 1.7.2.5 . Andere Versionen dürfen aber auch keine Probleme bereiten)
apt-get install git-core
- Danach wechseln wir in das Verzeichnis der ISPConfig Site, die wir gerade angelegt haben, damit die Weboberfläche später auch Zugriff auf die GIT Repositories hat und erstellen dort ein Verzeichnis für die GIT Repositorie. Um Probleme mit Berechtigungen und dem neuen Git Repository zu vermeiden, wechseln wir aber vorher noch den User zum korrekt (im Beispiel ist das “web1″, welcher das bei euch ist, könnt ihr aber über ein “ls -al” im entsprechenden Verzeichnis ablesen)
cd /var/www/scm.bit-dynamics.de/
su kundenname_trac
mkdir repositories
- Hier legen wir uns jetzt unser erstes Repository an, mit dem Namen “TESTProjekt”
- Als Antwort solltest du folgendes erhalten:
- Nun sollte im TESTProjekt Ordner ein Ordner “.git” vorhanden sein. Das ist auch schon dein Repository
- Nun noch wieder zurück in die Root Shell, denn als nächstes werden wir Trac installieren
cd repositories
mkdir TESTProjekt
cd TESTProjekt
git-init
Initialized empty Git repository in /var/www/clients/client1/web1/repositories/TESTProjekt/.git/
(Optional): Um den Pfad zu vereinfachen kann man den .git Ordner auch direkt in den /repositories/ Ordner verschieben und in den entsprechenden Projektnamen umbenenenn. Das ist aber rein kosmetischer Natur
exit
Trac installieren
- Um auch später bequem zusätzliche Komponenten für Trac installieren zu können, installieren wir die “python-setuptools” quasi ein apt-get für Python
- Nun laden wir die aktuelle Trac Version herunter und installieren diese (aktuell ist 12.2 als stable vorhanden, da im Squeeze Repo nur 11.7 und in Lenny etwas noch älteres liegt nehmen wir die aktuelle von der trac Webseiten)
- Um die Verbindung zu GIT herzustellen, benötigen wir noch ein zusätzliches Trac Plugin “Trac-Git”. Das bekommen wir ebenfalls über easy_install in der aktuellen Version und für Python 2.6
apt-get install python-setuptools
easy_install Babel==0.9.5
easy_install Trac
easy_install http://github.com/hvr/trac-git-plugin/tarball/master
Trac konfigurieren
- Um mehrere Trac Instanzen auf der gleichen Domain laufen zu lassen (wir haben pro Projekt eine Trac Instanz + ein GIT Repository), müssen wir noch weitere Ordner anlegen. Wir nehmen als Authentifikation das HTTP Basic Auth Verfahren und gehen davon aus, dass grundsätzlich jeder der einen Zugang hat auf alle Projekte zugreifen darf.
- Zuerst legen wir nun einen neuen “trac” Ordner außerhalb des /web Ordners an, in dem wir dann all unsere Trac Instanzen / Projekte einrichten können
- Nun legen wir unser Projekt an. Wir nennen es ‘Testprojekt’.
- “initenv” benötigen wir nur initial, um das Repository zu initialisieren. Generell kann man dann später über “trac-admin Testprojekt” bzw “trac-admin /pfad/zum/trac/projekt/Ordner” alle notwendigen Einstellungen setzen (Userberrechtigungen insbesondere)
- Als nächstes müssen wir Trac dazu bringen uns die .wsgi Datei zu erzeugen, damit wir auch über die in ISPConfig eingerichtete Adresse auf unsere Trac Instanzen zugreifen können. Dazu benutzen wir “deploy”
- Jetzt kopieren wir die .wsgi Datei aus dem Trac Deployment Ordner, den wir gerade angelegt haben, in den /web Ordner
- Als nächstes benötigen wir die .htpasswd Datei für die Basic Auth. Die legen wir auch außerhalb des /web Ordners an.
- Im nächsten Schritt konfigurieren wir dann noch den Apache Server über ISPConfig, um die richtigen Datien zu benutzen und die .wsgi Datei richtig zu interpretieren. Dafür öffnen wir in ISPConfig den Tab “Domains”, gehen auf “Domain”, wählen die richtige Domain aus und geben dann ins “Apache Direktiven” Feld unter dem Reiter “Optionen” den folgenden Code ein. Natürlich müssen unter Umständen noch die Pfade angepasst werde, bzw client1 und web1 durch eure Benutzer / Gruppe ersetzt werden!
- Zuletzt nun noch eurem Admin User alle Rechte auf das neue Trac Projekt geben:
- Wenn ihr alles richtig gemacht habt, solltet jetzt unter http://scm.HOST.tld eine Basic Auth nach einem Usernamen und Password fragen. Nach Eingabe solltet ihr eine Übersicht bekommen, welche Trac Instanzen alle existieren. In diesem Fall haben wir nur eine angelegt. Ihr könnt allerdings Schritt 2 (Schritt 9 nicht vergessen!) beliebig oft mit neuen Namen wiederholen, um weitere Trac Instanzen anzulegen.
su kundenname_trac
cd /var/www/clients/client1/web1/
mkdir trac
cd trac
trac-admin Testprojekt initenv
Name des Projekts [My Project]> <-- Eure Entscheidung, "Testprojekt" z.B.
Datenbankverbindungsstring [sqlite:db/trac.db]> <-- Enter, außer ihr wollt unbedingt gegen SQL connecten. Würde ich aber nicht machen, da die Performance mit sqlite passt und das Repository später besser zu backupen oder zu verschieben ist
trac-admin Testprojekt
deploy ./deploy
exit
cp ./Testprojekt/deploy/cgi-bin/trac.wsgi ../web/
cd ..
htpasswd -c .trac-htpasswd Admin
Password: <-- hier dann das Passwort für den User "Admin" eingeben
WSGIScriptAlias / /var/www/clients/client1/web1/web/trac.wsgi
WSGIDaemonProcess trac user=web1 group=client1
<directory /var/www/clients/client1/web1/web>
WSGIProcessGroup trac
WSGIApplicationGroup %{GLOBAL}
SetEnv trac.env_parent_dir /var/www/clients/client1/web1/trac
</directory>
<LocationMatch />
AuthType Basic
AuthName "Bit Dynamics Source Control"
AuthUserFile /var/www/clients/client1/web1/.trac-htpasswd
Require valid-user
</LocationMatch>
trac-admin trac/Testprojekt
permission add Admin TRAC_ADMIN
exit
trac.ini für Git Nutzung konfigurieren
Leider ist es damit noch nicht getan. Um Trac mit GIT nutzen zu können, müssen noch einige Einstellungen in der Trac.ini geändert werden, sowie neue für Git hinzugefügt. Ich liste im folgenden daher nur die zu Ändernden / Hinzu zu fügenden Werte auf.
- Die trac.ini liegt im Ordner der jeweiligen Trac Instanz
- Folgende Werte müssen so eingefügt / geändert werden:
cd trac/Testproject/conf
vi trac.ini
[components] tracext.git.git_fs.csetpropertyrenderer = enabled tracext.git.git_fs.gitconnector = enabled tracext.git.git_fs.gitwebprojectsrepositoryprovider = enabled [git] cached_repository = false git_bin = /usr/bin/git git_fs_encoding = utf-8 persistent_cache = false shortrev_len = 6 trac_user_rlookup = true use_committer_id = false use_committer_time = false wiki_shortrev_len = 7 [trac] repository_type = git
Weitere Optimierungsmöglichkeiten
- Auslagerung der trac.ini in eine zentrale Config Datei für alle Instanzen, um dann in jeder Instanz nur noch die gesonderten Parameter zu überschreiben
- Hinzufügen von “Hooks” zu Git, um ein Update von Trac Tickets direkt beim Einchecken von Code durchzuführen.
- Scheint bei uns nicht so ganz zu funktionieren, aber vielleicht habt ihr damit mehr Glück:
- Hinzufügen von “Hacks” zu Trac, um den Funktionsumfang zu erweitern.
Quellen für weitere Informationen
Detaillierte Informationen zu Trac finden sich im Trac Wiki.
