PHP Magazin

PHP, JavaScript, Open Web Technologies
X

Alles zu Facebook Hack findet Ihr in unserer neuen Serie: What the Hack?!

Verfolgt von Arbit

PHP-Projekte mit Arbit managen

Kore Nordmann

Die Idee für Arbit ist vor vier Jahren entstanden. Ziel: Ein in sauberem, getestetem PHP geschriebener, multiprojektfähiger, modularer Issue Tracker sollte her, der nach Belieben um Features, wie Wikis, Source Listings, Continuous Integration und Ähnliches erweitert werden kann. Das Ergebnis wird in diesem Artikel vorgestellt.

PHP Magazin

Der Artikel "PHP-Projekte mit Arbit managen" von Kore Nordmann ist erstmalig erschienen imPHP Magazin 4.2012

Als ich für meine Open-Source-Projekte keinen sinnvollen Issue Tracker finden konnte, weil die damaligen Lösungen für meine Zwecke entweder nicht erweiterbar oder schlicht unbenutzbar waren, setzen wir uns in der PHP UserGroup Dortmund zusammen und die ersten Ideen für Arbit erblickten das Licht der Welt. Diese ersten Ideen und Dokumente zu Arbit lassen sich immer noch im Wiki [1] finden und fassen die Intention, unter der Arbit entwickelt wurde, und immer noch wird, gut zusammen. Arbit liegt im Moment in einem Alpharelease vor. Im aktuellen Trunk sind allerdings mittlerweile alle ursprünglich geplanten Features implementiert, sodass Beta- und Stable-Releases bevorstehen. Arbit verlangt PHP 5.3 und funktioniert aktuell mit CouchDB als Datenbank. Ein MySQL Backend ist in Arbeit, allerdings funktioniert es noch nicht für alle Module. Weitere Abhängigkeiten sind nicht gegeben. Ziel ist es, dass Arbit auch auf Shared-Hosting-Systemen ohne Probleme läuft.

Die Module

Es gibt viele verschiedene Annahmen, was Module innerhalb einer Applikation sein können. Innerhalb von Arbit bezeichnen Module die Funktionalitäten, die für das Tracking eines Projektes zur Verfügung stehen. Eines der entscheidenden Module ist zum Beispiel das Issue-Tracking-Modul. Da jedes dieser Features als Modul umgesetzt wird, bleibt es dem Benutzer überlassen, welche Features er für sein Projekt einsetzen will. Insbesondere lassen sich auch ohne allzu großen Aufwand eigene Module implementieren. Aktuell sind folgende Module verfügbar:

  • Issue Tracker: Konfigurierbarer Issue Tracker mit Versionierung, Suchen, Filtern und Roadmap.
  • Wiki: Versioniertes Projekt-Wiki. Nutzt zurzeit REST als Dokumentenformat, weitere Formate werden in näherer Zukunft unterstützt.
  • Source: Das Source-Modul kann den Projekt-Quellcode aus SVN-, GIT-, Bazaar-, Mercurial- oder CVS-Repositories anzeigen und andere Module über Updates informieren.
  • PHPDoc: Zeigt per PHPDocumentor generierte API-Dokumentation der im Source-Modul verwalteten Software an.
  • PDepend Metrics: Übersicht über die mit PDepend ermittelten Sourcecode-Metriken. Werden zusätzlich direkt am Sourcecode annotiert.
  • Notification: Erlaubt das Verschicken von Events im System (Neue Issue, Commit etc.) per E-Mail. Geplant sind auch andere Kommunikationsmechanismen wie Jabber.
  • Build und Continuous Integration: Diese beiden Module machen Arbit zu einem Continuous-Integration-System. Das Build-Modul baut beliebige Projekte in beliebigen Sprachen, und die Ergebnisse werden im Continuous-Integration-Modul zur Präsentation aufbereitet.

Der Kern von Arbit übernimmt dagegen nur Basisaufgaben, wie das Routen der Requests, Benutzerverwaltung, Authentifizierung und das Verwalten der Projekte selbst. Arbit verwendet dabei Komponenten aus Apache Zeta Components, Symfony und Zend Framework. Einige besonders gut wiederverwendbare Teilprojekte von Arbit sind in eigene Komponenten ausgelagert worden, sodass sie auch von anderen verwendet werden können und mittlerweile auch werden.

Das Modulsystem

Primär sind alle Module natürlich eigenständige Elemente in der Applikation - der Issue Tracker funktioniert auch ohne irgendwelche anderen Module. Allerdings kommen einige modulübergreifende Nebenbedingungen hinzu. Im einfachsten Fall soll so zum Beispiel ein Commit mit der Nachricht "Fixed #23: Foo bar fails" das entsprechende Ticket im Issue Tracker schließen. Da sich eine Erläuterung einiger Aspekte des Modul-Systems mit einer Beschreibung der Funktionalität wunderbar verbinden lässt, wird dieser Artikel im Folgenden darauf eingehen.

Grundsätzlich werden in Arbit für alle wichtigen Ereignisse (Events) Signale gefeuert, die andere Module oder Komponenten in Empfang nehmen können. Diese so genannten Observer können dann anschließend auf diese Signale reagieren. Wenn eine neue Issue angelegt wird, so wird im Falle von Arbit zum Beispiel ein trackerNewIssue-Signal gefeuert. Jedes andere Modul, das sich für dieses Signal interessiert, kann dann einen so genannten Slot bereitstellen und wird über diesen über das Signal informiert.

Für das Signal trackerNewIssue interessiert sich zum Beispiel das Notification-Modul, das dann eine E-Mail an alle an der Issue Beteiligten herausschickt. Außerdem stellt das Notification-Modul die Möglichkeit bereit, bestimmte Signale zu abonnieren, sodass man sich zum Beispiel über jede neue Issue per E-Mail informieren lassen kann. Diese Signal-Notification-Konvertierung ist das einfachste Beispiel für das Signal-Handling und wird in Arbit dafür verwendet, dass man sich als Benutzer über nahezu jedes Ereignis im Projekt-Tracker informieren lassen kann.


Themen der nächsten Seiten
  • Pattern: Signal Slot
  • Sourcecode-Integration
  • Kontinuierliche Integration
  • Grafische Aufbereitung
  • Status
  • Informationen zum Autoren
 

Kommentare

Ihr Kommentar zum Thema

Als Gast kommentieren:

Gastkommentare werden nach redaktioneller Prüfung freigegeben (bitte Policy beachten).