Schlagwort-Archiv: Agile

PHP meets Maven

Veröffentlicht am von
Antworten

[Teil 1] [Teil 2] [Teil 3] [Teil 4]

Wikipedia liefert für den Begriff Maven folgende Erklärung: »Ein Maven ist ein Experte, der andere berät und deren Entscheidungen beeinflusst«. Wegen seiner Bedeutung wurde der Begriff Maven für die Namensgebung der Software auserkoren. Jason van Zyl, Gründer und CTO von Sonatype, beschreibt das Programm mit folgenden Worten: »Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project’s build, reporting and documentation from a central piece of information.«

Maven ist ein in Java geschriebenes plattformunabhängiges Projektmanagement-Tool. Es ist ein Open-Source-Projekt der Apache Software Foundation und frei erhältlich. In der Version 2 wurde das Programm völlig neu entwickelt. Das ist auch ein Grund dafür, dass Erweiterungen der Version 2 nicht abwärtskompatibel sind. Derzeit ist die Version 3 aktuell, welche auch mit Maven-2-Projekten kompatibel ist.

Wie bereits angedeutet, handelt es sich bei Maven um ein schlankes Werkzeug, das durch seinen modularen Aufbau problemlos durch eigene Plug-ins erweitert werden kann. Diese Möglichkeit nutzt das Projekt Maven for PHP und stellt eigene Erweiterungen für PHP bereit.

Bild 1: Homepage des Projekts Maven for PHP

Bevor wir nun mit der Installation der Software beginnen, ist es notwendig, etwas über das Konzept von Maven zu erfahren, da dieses Werkzeug mächtiger ist als sein Pendant Ant.

Maven erzeugt aus Java-Quellcode Binärdateien. Die hohe Akzeptanz erreichte das Tool aber durch das transitive Auflösen von Abhängigkeiten zu anderen Softwarebibliotheken. Im Maven-Jargon werden Bibliotheken oder Module als Artefakt bezeichnet. Das Verwalten von Artefakten ist allerdings nur ein kleiner, wenn auch sehr maßgeblicher Aspekt für den Einsatz in PHP-Projekten.

Nicht ohne Grund stellt Maven an sich selbst den Anspruch, ein Projekt-Management-Werkzeug zu sein. Im Projektalltag wird zwischen drei verschiedenen Einsatzbereichen unterschieden. Der umfangreichste Teil ist der Build-Life-cycle mit seinen 21 Unterschritten, die als Phase bezeichnet werden. Die Teilbereiche einer Phase werden wiederum als Goal bezeichnet. So erreicht man eine feingranulare Struktur, in die sich leicht eigene Funktionen einbringen lassen. Ein anderer Aspekt ist die Reporting-Engine, die ihre Arbeit unter dem Site-Lifecycle verrichtet. Für das Aufräumen nach dem vollendeten Werk ist der Clean-Lifecycle zuständig. Was es mit den einzelnen Lifecycles auf sich hat wird an späterer Stelle noch detaillierter geklärt.

Zentrale Steuereinheit

Im Wurzelverzeichnis eines Projekts liegt die zentrale Steuereinheit. Es handelt sich dabei um eine einfache XML-Datei mit dem Namen pom.xml, in der die gesamte Konfiguration des Projekts vorgehalten wird. Die Bezeichnung POM steht im Übrigen für Project Object Model. Bei umfangreichen Projekten kann diese Datei schnell eine beachtliche Größe erlangen. Aus diesem Grund verfolgt Maven das Prinzip »Don’t repeat yourself« (DRY) und »Convention over Configura tion« (COC). Das besagt, es müssen lediglich die Dinge in der POM-Datei eingetragen werden, die vom vorgegeben Standard abweichen. Um den Überblick auch zu einem späteren Zeitpunkt nicht zu verlieren, ist es sehr ratsam, nur in absoluten Ausnahmefällen vom Standard abzuweichen.

Nachdem Sie nun die wichtigsten Begriffe kennen, können wir zur ersten Tat schreiten und die Software installieren.

Schnell installierte Basis

Bild 2: Einstellungen der Umgebungs­variablen unter Windows

Für Maven existiert keine Installationsroutine, wie sie beispielsweise in Windows-Systemen üblich ist. Da das Programm in Java geschrieben ist, muss ein aktuelles Java-SDK auf dem System bereits vorhanden sein. Nach dem erfolgreichem Download und dem anschließenden Entpacken des Archivs sind folgende Schritte auszuführen:

  • Setzen der Umgebungsvariablen JAVA_HOME = {install.java},
  • Setzen der Umgebungsvariablen M2_HOME = {install.maven},
  • Erweitern der PATH-Variable %M2_HOME%\ bin und %JAVA_HOME%\bin.

Mit {install.maven} ist der Ort des ausgepackten Maven-Archivs gemeint. Unter Windows 7 ist die Einstellung der Umgebungsvariablen über die Systemsteuerung hinter der Option System versteckt, die sich dort über den Punkt Erweiterte Systemeinstellungen öffnen lässt. Bei geglückter Installation quittiert Maven die Konsolenausgabe für mvn -vers

Bild 3: Ausgabe der Konsole bei erfolg­reicher Maven-Installation

Dependency Management

Bild 4: Auszug aus einem lokalen Repository

Wie Sie bei der Installation bemerkt haben, ist der Kern von Maven recht kompakt. Die umfangreichen Funktionen werden durch Erweiterungen über die Plug-in-Schnittstelle realisiert. Soll beispielsweise eine Dokumentation mit der Anweisung mvn site erzeugt werden, holt sich Maven die notwendigen Artefakte über das Internet und speichert diese auf dem Rechner in einem lokalen Repository. Die Dateien sind im Home-Verzeichnis des aktuellen Benutzers unter .m2/repository/ zu finden. Wenn man sich die Ordnerstruktur aus Bild 4 ein wenig genauer ansieht, kann man erkennen, dass Maven die Artefakte nach Namen und Versionsnummer organisiert. In dem Screenshot sind im lokalen Repository für das Test-Framework JUnit vier unterschiedliche Versionen mit der dazugehörigen POM-Datei hinterlegt. Anhand des POM ist Maven nun in der Lage, die notwendigen Abhängigkeiten von JUnit ebenfalls aufzulösen. Die Archivierung der Versionen eines Artefakts ermöglicht es später, in einem Projekt innerhalb kürzester Zeit für eine Bibliothek die neueste Version auszuprobieren und im Fall einer Inkompatibilität die Änderung in wenigen Augenblicken wieder rückgängig zu machen. Es muss lediglich in der POM-Datei die Versionsnummer des Artefakts geändert werden.

Ein weiterer Vorteil ist, dass im Konfigurationsmanagement die verwendeten Artefakte nicht mehr archiviert werden müssen. Diese Arbeit übernimmt nun künftig in zuverlässiger Weise Maven. Dank dieses Umstands werden im Konfigurationsmanagement einige MByte an Speicher eingespart, was bei größeren Projekten mit vielen Artefakten einiges an Zeit beim Checkout einsparen kann. Eine Entlastung des Netzwerks ist eine weitere angenehme Randerscheinung.

Nun stellt sich berechtigterweise die Frage, von welchem Server Maven die benötigten Artefakte beziehen kann? Neben dem standardmäßig eingestelltem Remote-Repository repo1.maven.org können auch andere Repositories hinzugefügt werden. Dazu ist die Maven-Installation über die Datei settings.xml den eigenen Bedürfnissen anpassen. Hierbei können zwei Stufen genutzt werden:

  • User Level: Im Home-Directory des aktuellen Nutzers legt Maven den Ordner .m2 an, in dem die settings.xml zu finden ist. Dies ist vor allem im Mehrbenutzerbetrieb nützlich, da hier Passwörter für Logins et cetera hinterlegt werden können.
  • Global Level: Die Datei settings.xml ist in diesem Fall im Ordner conf der Maven-Installation abgelegt. Diese Konfiguration gilt für alle Nutzer auf einem System.

Die Konfiguration über die settings.xml ist projektübergreifend und enthält beispielsweise Einträge für das Login zum Versionskontrollsystem (SCM), den Pfad zum lokalen Repository beziehungsweise zu weiteren Remote-Repositories. Um PHP Maven nutzen zu können, muss das öffentliche Repository in einer der beiden Settings-Dateien eingetragen werden. Listing 1 enthält die hierfür notwendige Konfiguration.

Der Codeblock aus dem Listing ist in einer der settings.xml-Dateien unterhalb der Ebene des Root-Elements einzutragen. Die eigentliche Konfiguration befindet sich im Profil mit der ID profile-php-maven, welches auch als aktiv registriert ist. Es ist ohne Weiteres möglich, mehrere Profile in der Konfiguration aktiv zu setzen, wenn dies notwendig sein sollte. Im Profil werden die verschiedenen Remote-Repositories für PHP Maven registriert. Mit diesen Einträgen ist Maven nun in der Lage, die notwendigen Artefakte aus dem öffentlichen Repository zu laden.

<activeProfiles>
    <activeProfile>profile-php-maven</activeProfile>
</activeProfiles>

<profiles>
	<profile>
	<id>profile-php-maven</id>
	<pluginRepositories>
		<pluginRepository>
			<id>release-repo1.php-maven.org</id>
			<name>PHP-Maven 2 Release Repository</name>
			<url>http://repos.php-maven.org/releases</url>
			<releases>
				<enabled>true</enabled>
			</releases>
		</pluginRepository>

		<pluginRepository>
			<id>snapshot-repo1.php-maven.org</id>
			<name>PHP-Maven 2 Snapshot Repository</name>
			<url>http://repos.php-maven.org/snapshots</url>
			<releases>
				<enabled>false</enabled>
			</releases>
			<snapshots>
				<enabled>true</enabled>
			</snapshots>
		</pluginRepository>
	</pluginRepositories>

	<repositories>
		<repository>
			<id>release-repo1.php-maven.org</id>
			<name>PHP-Maven 2 Release Repository</name>
			<url>http://repos.php-maven.org/releases</url>
			<releases>
				<enabled>true</enabled>
			</releases>
		</repository>
		<repository>
			<id>snapshot-repo1.php-maven.org</id>
			<name>PHP-Maven 2 Snapshot Repository</name>
			<url>http://repos.php-maven.org/snapshots</url>
			<releases>
				<enabled>false</enabled>
			</releases>
			<snapshots>
				<enabled>true</enabled>
			</snapshots>
		</repository>
	</repositories>
	</profile>
</profiles>

Mittlerweile betreiben immer mehr Unternehmen eigene Repository-Server für ihre Produkte. Dazu gehören unter anderem Google, Java .NET und Activity, um einige öffentliche Server zu nennen. Da das Projekt Maven for PHP vergleichsweise sehr jung ist, sind derzeit nur die bekanntesten PHP-Projekte, wie beispielsweise Zend und Symfony, in das Repository migriert. In absehbarer Zukunft darf jedoch durchaus erwartet werden, dass weitere PHP-Projekte das Repository bereichern werden. Bei besonders dringlichen Fällen kann es hier hilfreich sein, eine Anfrage über die Google Mailing List zu stellen. Natürlich ist auch jeder, der sich an PHP for Maven beteiligen möchte, eingeladen, sich im Rahmen seiner Möglichkeiten einzubringen.

PHP-CLI

Damit Maven sich voll entfalten kann, ist es notwendig, das Command Line Interface (CLI) für PHP in der Konsole zu aktivieren. Mit dem CLI ist es möglich, PHP-Skripts ohne Webbrowser direkt auf der Kommandozeile auszuführen.

Bild 5: Output des Prompts für erfolgreiches Einbinden des PHP-CLI

Diese Funktion wird beispielsweise benötigt, um die Source-Code-Dokumentation über den phpDocumentor aus Maven heraus anzustoßen. Sobald der Pfad zum Verzeichnis der php.exe in die PATH-Variable aufgenommen wurde, können PHP-Skripts über die Konsole ausgeführt werden. Wie diese Aufgabe für Windows-Systeme gelöst wird, wurde bereits in dem vorangegangenen Abschnitt über die Installation ausführlich beschrieben. Der Erfolg dieser Bemühung lässt sich durch die Anweisung php –v rasch überprüfen und wird im Erfolgsfall mit der Ausgabe der installierten PHP-Version quittiert. Auch wenn im ersten Blick die Installation umfangreich erscheint, sind nur wenige Schritte durchzuführen, um ein einsatzfähiges System zu erhalten. Der geringe Aufwand wird durch umfangreiche Funktionen zur Projektautomatisierung schnell entlohnt.

Ein Füllhorn an Möglichkeiten

Es steht dem Benutzer frei, für welches Szenario er Maven in einem Projekt einsetzen möchte. Hier ein Liste möglicher Einsatzszenarien:

Die erste Position dieser Liste führt erwartungsgemäß das Dependency Management an. Über den Mechanismus können Artefakte fremder Hersteller ebenso dem eigenen Projekt hinzugefügt werden wie selbst entwickelte Bibliotheken.

Neben diesem Aspekt ist ein weiteres wichtiges Thema der Softwaretest. Maven erlaubt es, verschiedenste Test-Frameworks im Build-Lifecycle zu integrieren. Der bekannteste Vertreter unter den Unit-Tests, phpUnit, ist bereits im Public-Repository von Maven for PHP enthalten.

Wie bereits angedeutet, kommt die Generierung der API-Dokumentation mit dem phpDocumentator ebenfalls nicht zu kurz.

Aber auch ein Blick zu den klassischen Maven-Plug-ins ist in einigen Fällen lohnenswert. So besteht die Möglichkeit, aus Maven heraus Ant-Aufrufe zu starten und abzuarbeiten, was die Funktionsvielfalt um einiges erweitert.

Ein beliebtes Thema für Webseiten sind script- und CSS-Minimierer. Code-Beautifier oder Obsfukatoren stellen weitere Punkte auf der Liste dar. Auch Code-Analyzer-Werkzeuge wie Checkstyle können eingebunden werden und bieten damit der Projektleitung einen guten Einblick in die Softwarequalität.

Eine weitere Möglichkeit besteht darin, ganze Internetseiten zu generieren. So ist beispielsweise die Homepage des Projekts aus Maven heraus erzeugt worden.

Das Charmante an all diesen Möglichkeiten ist die Tatsache, dass für die Funktionalität keine weitere Software installiert werden muss. Alle Funktionen sind durch Maven-Plug-ins umgesetzt und werden bei Bedarf über das Dependency Management nachgeladen. Sollte dennoch Wünsche offen bleiben, ist es jederzeit möglich, über das Plug-in-API eigene Erweiterungen zu schreiben.

Für Unternehmen bietet Maven einen weiteren Vorteil. Der Einsatz dieses Werkzeugs unterstützt bei gutem Moduldesign die Wiederverwendung von Softwarekomponenten. Diese Tatsache kann den entscheidenden Vorsprung gegenüber der Konkurrenz bedeuten, da Projekte schneller abgewickelt werden können.

So wird Unternehmenswissen greifbar

Veröffentlicht am von
Antworten

Das Fachwissen der eigenen Mitarbeiter ist für jede Organisation ein bedeutender Wirtschaftsfaktor. Umso wichtiger ist es, die Erfahrungen und Fachkenntnisse dauerhaft zu speichern und anderen Mitarbeitern zur Verfügung zu stellen. Ein zentraler Knowledge-Management-Server übernimmt diese Aufgabe und hilft, langfristig die Produktivität im Unternehmen zu sichern.

(c) 2011 Marco Schulz, Materna Monitor, Ausgabe 2, S.32-33

Die Komplexität der heutigen stark vernetzten Arbeitswelt erfordert ein reibungsloses Zusammenspiel unterschiedlichster Spezialisten. Eine wichtige Rolle spielt hierbei der Wissenstransfer. Erschwert wird dieser Austausch, wenn die Teammitglieder an unterschiedlichen Standorten mit verschiedenen Zeitzonen arbeiten oder aus anderen Kulturkreisen kommen. Unternehmen mit weltweiten Standorten kennen diese Problematik und haben entsprechende Strategien für ein unternehmensweites Wissens-Management entwickelt. Um dieses erfolgreich einzuführen, sollte die einzusetzende IT-Lösung als Methodik aufgefasst werden anstatt das eigentliche Werkzeug in den Vordergrund zu stellen. Haben die Verantwortlichen die Entscheidung für eine bestimmte Software-Lösung getroffen, sollte diese auch konsequent beibehalten werden. Ein häufiger Systemwechsel mindert die Qualität der Verknüpfungen zwischen den gespeicherten Inhalten. Da es keinen normierten Standard für die Repräsentation von Wissen gibt, können bei einem Wechsel auf neue Software-Lösungen erhebliche Konvertierungsverluste eintreten.

Verschiedene Mechanismen für unterschiedliche Inhalte

Informationen lassen sich in IT-Systemen auf verschiedene Weise speichern. Die einzelnen Repräsentationsformen unterscheiden sich durch die Darstellung, Strukturierung und Verwendung. Um Dokumente gemeinsam konfliktfrei bearbeiten und gleichzeitig versionieren zu können, wie es bei Spezifikationen oder Dokumentationen notwendig ist, eignen sich Wikis [1] optimal, da sie genau für diesen Einsatz ursprünglich entwickelt wurden. Die dort gespeicherten Dokumente sind üblicherweise projektspezifisch und sollten auch so organisiert werden.

Projektübergreifende Dokumente im Wiki sind zum Beispiel Fachworterklärungen, ein zentrales Abkürzungsverzeichnis oder ein Who is Who der Unternehmensmitarbeiter inklusive Kontaktdaten und Themengebieten. Letztere lassen sich wiederum mit der Fachworterklärung verknüpfen. Übergreifende Inhalte können dann zentral aktuell gehalten werden und lassen sich komfortabel in die entsprechenden Projektdokumente verlinken. Dieses Vorgehen vermeidet unnötige Wiederholungen und die zu lesenden Dokumente werden kürzer, enthalten aber dennoch alle notwendigen Informationen. Johannes Siedersleben hat bereits 2003 in seinem Buch Softwaretechnik [2] die Risiken zu langer Dokumentationen beschrieben.

Wissen, das eher den Charakter einer FAQ aufweist, sollte besser über ein Forum organisiert werden. Die Gruppierung nach Themen, in denen Fragen nach dem Muster „Wie kann ich …?“ hinterlegt sind, erleichtern das Auffinden möglicher Lösungen. Besonders attraktiv ist die Tatsache, dass ein solches Forum sich mit der Zeit dem Bedarf nach weiterentwickelt. Denn Nutzer haben die Möglichkeit, eigene Fragen zu formulieren und in das Forum einzustellen. In aller Regel lassen qualifizierte Antworten auf neu gestellte Fragen nicht lange auf sich warten.

Geeignete Kandidaten für Blogs sind zum Beispiel allgemeine Informationen zum Unternehmen, Statusberichte oder Tutorials. Dies sind Dokumente, die eher einen informativen Charakter haben, nicht formgebunden sind oder sich schwer einem speziellen Thema zuordnen lassen. Kurzinformationen (Tweets [3]) über Twitter, die in Kanälen thematisch zusammengefasst sind, können die Projektarbeit ebenfalls bereichern. Sie minimieren zusätzlich die E-Mails im eigenen Postkasten. Beispiele dafür sind Reminder zu einem bestimmten Event, ein Newsflash zu neuen Produktversionen oder eine Information über einen erfolgreich abgeschlossenen Arbeitsprozess. Tweets in die Projektarbeit zu integrieren, ist relativ neu und entsprechend rar sind hierfür geeignete Software-Lösungen.

Natürlich ist die Aufzählung von Möglichkeiten an dieser Stelle bei weitem noch nicht erschöpft. Die Beispiele vermitteln aber bereits einen guten Überblick, wie Unternehmen ihr Wissen organisieren können. Mit der Verknüpfung der einzelnen Systeme zu einem Portal [4], das eine übergreifende Suche und Benutzerverwaltung hat, entsteht so schnell ein Netzwerk, das sich auch als Cloud-Lösung eignet.

Für die Akzeptanz einer Wissensplattform ist die Anwenderfreundlichkeit ein entscheidender Faktor. Lange Einarbeitungszeiten, unübersichtliche Strukturierungen und eine umständliche Bedienung können schnell zur Ablehnung führen. Mit einer Zugangsberechtigung zu den einzelnen Inhalten auf Gruppenebene wird auch der Sicherheit genüge getan. Ein gutes Beispiel dafür ist das Enterprise Wiki Confluence [5]. Es ermöglicht, den einzelnen Dokument-Ebenen verschiedene Lese- und Schreib-Berechtigungen zuzuordnen.

Naturgemäß kann man von einem Entwickler nicht erwarten, dass er nach erfolgreicher Implementierung sein Werk mit den richtigen Worten für die Nachwelt verständlich beschreibt. Dass die Qualität der Texte in vielen Dokumentationen nicht immer ausreichend ist, hat auch die Hochschule Merseburg erkannt und bietet den Studiengang Technische Redaktion [6] an. Als geeignetes Mittel zur Qualitätssicherung der Inhalte hat sich daher das Querlesen durch andere Projektmitglieder erwiesen. Um das Verfassen von Texten zu erleichtern, ist es hilfreich, einen kleinen Leitfaden – ähnlich der Coding Convention – bereitzustellen.

Fazit

Eine Wissensdatenbank lässt sich nicht von heute auf morgen umsetzen. Es braucht Zeit, bis darin genügend Informationen zusammengetragen sind. Erst durch Interaktion und Korrekturen von Unverständlichkeiten erreicht das Wissen eine Qualität, die zum Transfer einlädt. Jeder Mitarbeiter sollte dazu ermutigt werden, vorhandene Texte mit neuen Erkenntnissen anzureichern, unverständliche Passagen aufzulösen oder Suchbegriffe zu ergänzen. Wenn der Prozess der Wissensschöpfung und Verteilung in dieser Form gelebt wird, werden weniger Dokumente verwaisen und die Informationen sind stets aktuell.

Ressourcen

Abonnement / Subscription

[English] This content is only available to subscribers.

[Deutsch] Diese Inhalte sind nur für Abonnenten verfügbar.

Automatisierungsmöglichkeiten im Software-Konfigurations-Management

Veröffentlicht am von
Antworten

Die Software-Entwicklung bietet einige äußerst effiziente Möglichkeiten, wiederkehrende Handgriffe durch Automatisierung zu vereinfachen. Das Wegfallen lästiger, sich wiederholender, monotoner Aufgaben und eine dadurch reduzierte Fehlerhäufigkeit im Entwicklungsprozess sind längst nicht alle Facetten dieser Thematik.

(c) 2011 Marco Schulz, Materna Monitor, Ausgabe 1, S.32-34

Die Motivation, Automatismen in der IT-Landschaft zu etablieren, ist weitgehend die Gleiche. Wiederkehrende Aufgaben sollen vereinfacht und ohne menschliches Zutun maschinell gelöst werden. Die Vorteile sind weniger Fehler bei der Benutzung von IT-Systemen, was wiederum die Kosten senkt. So einfach und vorteilhaft sich der Gedanke der selbstständig ablaufenden Prozesse auch anhört, die Umsetzung ist weniger trivial. Schnell wird klar, dass für jede identifizierte Möglichkeit einer Automation nicht immer eine Umsetzung machbar ist. Auch hier gilt der Grundsatz: Je komplexer ein Problem ist, umso aufwendiger ist dessen Lösung.

Um abzuwägen, ob sich der wirtschaftliche Aufwand zur Einführung bestimmter Automatismen lohnt, müssen die Kosten einer manuellen Lösung mit dem Faktor der zu wiederholenden Häufigkeit dieser Arbeit multipliziert werden. Diesen Kosten sind die Aufwendungen für die Entwicklung und den Betrieb der automatisierten Lösung entgegenzusetzen. Anhand dieser Gegenüberstellung wird schnell klar, ob ein Unternehmen die angedachte Verbesserung durchführen sollte.

Tools unterstützen den Entwicklungsprozess

Besonders bei der Entwicklung von Software-Projekten gibt es einen erhebliches Optimierungspotenzial durch automatische Prozesse. Dabei unterstützen die Entwickler eine Vielzahl an Tools, die es gekonnt zu orchestrieren gilt. Besonders das Konfigurations- und Release-Management beschäftigt sich sehr ausführlich mit dem praktischen Einsatz verschiedenster Werkzeuge zur Automatisierung des Software-Entwicklungsprozesses.

Das Vorhandensein einer separaten Build-Logik, beispielsweise in Form eines simplen Shell-Skriptes, ist zwar bereits ein guter Ansatz, aber nicht immer zielführend. Für solche Fälle sind plattformunabhängige Lösungen notwendig, da die Entwicklung mit sehr hoher Wahrscheinlichkeit in einem heterogenen Umfeld stattfindet. Eine Insellösung bedeutet stets erhöhten Anpassungs- und Pflegeaufwand. Schließlich sollen die Automatisierungsbestrebungen vorhandene Abläufe vereinfachen. Aktuelle Build-Werkzeuge wie Maven und Ant nutzen diesen Vorteil der Plattformunabhängigkeit. Die Kapselung der gesamten Build-Logik erfolgt bei beiden Werkzeugen in separaten XML-Dateien. Da sich XML bereits als Standard in der Software-Entwicklung etabliert hat, ist die Lernkurve steiler als bei rudimentären Lösungen.

Die Nutzung zentraler Build-Logiken bildet die Grundlage für weitere Automatismen während der Entwicklungsarbeit. Einen Aspekt bilden dabei automatisierte Tests in Form von UnitTests in einer Continuous-Integration-(CI)-Umgebung. Eine CI-Lösung fügt alle Teile einer Software zu einem Ganzen zusammen und arbeitet alle definierten Testfälle ab. Konnte die Software nicht gebaut werden oder ist ein Test fehlgeschlagen, wird der Entwickler per E-Mail benachrichtigt, um den Fehler schnell zu beheben. Moderne CI-Server werden gegen ein Versionsverwaltungssystem, wie beispielsweise Subversion oder Git, konfiguriert. Das bewirkt, dass der Server ein Build erst dann beginnt, wenn auch tatsächlich Änderungen im Sourcecode gemacht wurden.

Komplexe Software-Systeme verwenden in aller Regel Abhängigkeiten zu fremden Komponenten (Bibliotheken), die nicht durch das eigene Projekt beeinflusst werden können. Die effiziente Verwaltung der im Projekt verwendeten Artefakte ist die Hauptstärke des Build-Tools Maven, was zu dessen starker Verbreitung beigetragen hat. Bei richtiger Verwendung ist es so nicht mehr nötig, binäre Programmteile innerhalb der Versionsverwaltung zu archivieren, was zu kleineren Repositories und kürzeren Commit-Zeiten (erfolgreicher Abschluss einer Transaktion) führt. Neue Versionen der verwendeten Bibliotheken können schneller eingebunden und ausprobiert werden, ohne dass sie fehleranfällige manuelle Kopieraktionen verursachen. Inhouse entwickelte Bibliotheken lassen sich im Sinne der Wiederverwendung mit der Verwendung eines eigenen Repository-Servers (Apache Nexus) im Firmennetzwerk auf einfache Weise geschützt verteilen.

Bei der Evaluierung eines Build-Werkzeuges sollte die Möglichkeit des Reportings nicht vernachlässigt werden. Die automatisierte Überwachung der Code-Qualität anhand von Metriken, beispielsweise durch das Tool Checkstyle, ist ein hervorragendes Instrument für die Projektleitung, um den aktuellen Stand des Projekts realistisch zu beurteilen.

Nicht zu viele neue Technologien

Bei allen Möglichkeiten, Prozesse zu automatisieren, können mehrere Wege beschritten werden. Nicht selten führen Entwicklerteams lange Diskussionen darüber, welches Werkzeug besonders für das aktuelle Projekt geeignet ist. Diese Frage lässt sich schwer allgemein beantworten, da jedes Projekt einzigartig ist und die Vor- und Nachteile verschiedener Werkzeuge mit den Projektanforderungen abgeglichen werden müssen.

Im praktischen Einsatz hat sich die Beschränkung auf maximal zwei neuartige Technologien im Projekt bewährt. Ob ein Werkzeug geeignet ist, entschiedet auch die Tatsache, ob im Unternehmen Personen mit dem geeigneten Know-how verfügbar sind. Eine gute Lösung ist eine vom Management freigegebene Liste mit Empfehlungen der eingesetzten Tools, die bereits verwendet werden oder sich in die bestehende Systemlandschaft integrieren lassen. Damit wird sichergestellt, dass die eingesetzten Werkzeuge übersichtlich und beherrschbar bleiben.

Projekte, die über viele Jahre laufen, müssen sich in größeren Abständen einer Modernisierung der verwendeten Technologien unterziehen. In diesem Zusammenhang müssen geeignete Zeitpunkte gefunden werden, um mit möglichst wenig Aufwand zur neuen Technologie zu migrieren. Sinnvolle Termine, um auf eine neuere Technologie zu schwenken, sind beispielsweise ein Wechsel auf ein neues Major Release des eigenen Projektes. Dieses Vorgehen erlaubt eine saubere Trennung, ohne alte Projektstände auf die neue Technik migrieren zu müssen. In vielen Fällen ist das auch nicht so einfach möglich.

Fazit

Die Verwendung von Automatismen zur Software-Entwicklung kann bei bedachtem Einsatz das Erreichen des Projektziels tatkräftig unterstützen. Wie bei allen Dingen ist der übermäßige Einsatz mit einigen Risiken verbunden. Die verwendete Infrastruktur muss bei aller Technisierung verständlich und beherrschbar bleiben, so dass bei Systemausfällen die Projektarbeit nicht ins Stocken gerät.

Kontrollzentrum

Veröffentlicht am von
Antworten

Seit einiger Zeit steht die neue Version 1.5 des Versionsverwaltungs-Tools Subversion (SVN) zum kostenlosen Download bereit. Das Programm ist für verschiedene Plattformen erhältlich, dazu zählen Windows und Linux als die wichtigsten Vertreter. Der Artikel bezieht sich zwar auf das Windows-Betriebssystem, aber mit geringem Aufwand lassen sich die wenigen spezifischen Unterschiede leicht adaptieren. Man kann Subversion auf unterschiedliche Art und Weise betreiben. Für eine lokale Verwendung, bei sehr kleinen Projekten mit lediglich einem einzigen Entwickler, genügt oft die Installation eines Clients. Für Windows Systeme sollte die Wahl des Clients auf TortoiseSVN fallen. Die Anwendung arbeitet als Explorer-Erweiterung und beherrscht alle notwendigen Funktionen zur Arbeit mit SVN. Dazu zählt unter anderem das Anlegen der Projektverzeichnisse, die Repository genannt werden. Der Zugriff auf ein lokales Repository erfolgt über das file:///-Protokoll. Sobald das Repository für mehrere Entwickler bereitstehen soll, wird ein Server benötigt. Man hat die Wahl zwischen einem Standalone-Server oder einer Integration in den Apache Web Server. Die aktuelle Version des SVN-Servers bringt für Windows-Nutzer eine Verbesserung der Konfiguration als Windows-Dienst. Für den Standalone-Server stehen die Protokolle svn:// und svn+ssh:// zur Verfügung. Für diesen Artikel wird vor allem auf die Installation des Apache-Moduls eingegangen. Der Vorteil des Apache liegt darin, mit den Protokollen http:// und https:// auf die Projektverzeichnisse zugreifen zu können. Mit Subclipse liefert Tigris.org SVN als Plug-in für Eclipse, das dem Tortoise-Client kaum in etwas nachsteht. Dank der PHP-Tools ist die Eclipse-IDE nicht mehr nur von Java-Programmierern geschätzt. Abbildung 1 zeigt die Subversion View mit einem geöffneten Projekt in Eclipse.

Abb. 1: Eclipse in der Subversion-Ansicht mit einem geöffneten Projekt

Subversion im Apache

Eine sehr bequeme Möglichkeit Subversion zu nutzen, ist die Integration in den Apache Web Server; damit kann das Repository über das HTTP-Protokoll angesprochen werden. Die Installation ist nicht weiter schwierig, erfordert allerdings eine funktionsfähige Apache-Installation. Wer die aufwändige Installation einer vollständigen Serverumgebung scheut, kann getrost auf XAMPP [4] zurückgreifen. Als Erstes müssen dann die Binaries des SVN für den Apache 2.2.X von der Webseite [5] geladen werden. Die Dateien mod_dav_svn.so, mod_authz_svn.so und der Ordner iconv sind in das Verzeichnis %APACHE_HOME%\modules zu kopieren. Um die Module dem Webserver bekannt zu machen, muss schließlich die Datei httpd.conf im Verzeichnis conf des Apache gemäß Listing 1 editiert werden.

# Anpassungen der httpd.conf
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so

Include conf/svn.conf
Plaintext

Die ersten beiden Zeilen aktivieren die SVN-Module für den Apache. Um die Konfigurationsdatei übersichtlich zu halten, wird die eigentliche Konfiguration von Subversion über die Anweisung aus Zeile drei in die Datei svn.conf ausgelagert (Listing 2). Die Datei muss im gleichen Verzeichnis wie die httpd.conf angelegt werden.

<IfModule dav_svn_module>
  <Location /svn>
    DAV svn
    SVNListParentPath on
    SVNParentPath D:\Subversion
  </Location>
</IfModule>
XML

Über den Eintrag wird die darin eingeschlossene Konfiguration nur dann ausgeführt, wenn das Modul dav_svn_module wie in Listing 1 aktiviert wurde. bestimmt den Pfad, wie das Repository angesprochen werden soll. In diesem Fall ist http://127.0.0.1/svn der korrekte URL, um auf die Repositories zuzugreifen. Der absolute Pfad, in dem die Projektverzeichnisse abgelegt werden, wird mit dem Eintrag SVNParentPath gesetzt. Die Option SVN-ListPArentPath on listet alle Repositories in D:/Subversion über den URL http://localhost/svn auf. Kommentare werden mit # in Apache-Konfigurationsdateien eingeleitet und gelten nur bis zum Zeilenende. Sobald die Konfiguration abgeschlossen ist, muss der Server neu gestartet werden, um die Änderungen wirksam zu machen.

Das Repository

Wie schon erwähnt, heißt das Projektverzeichnis, das von SVN verwaltet wird, Repository. Für jedes Projekt wird üblicherweise ein eigenes Repository verwendet, es ist aber auch möglich, mehrere Projekte in einem gemeinsamen Verzeichnis abzulegen. Neue Projekte werden im Hauptverzeichnis Subversion angelegt, das für den Apache konfiguriert wurde. Für unser Beispiel aus Listing 2 ist dieses Hauptverzeichnis D:/Subversion. Darin wird ein neuer Ordner erzeugt, der den Namen des Projekts erhält. Im nächsten Schritt wird in dem neuen Ordner das eigentliche Repository generiert. Dazu wird mit einem Rechtsklick auf den Ordner, der das Projektverzeichnis beherbergen soll, der Eintrag TortoiseSVN/Projektverzeichnis hier erstellen ausgewählt. Die notwendigen Schritte werden von Tortoise anschließend automatisch ausgeführt und das Projektverzeichnis kann nun benutzt werden. Die von SVN angelegte Ordnerstruktur sollte nun nicht weiter verändert werden, alle Zugriffe auf das Verzeichnis erfolgen über den SVN-Client Tortoise.

In den einzelnen Repositories hat es sich bewährt, die Unterverzeichnisse trunk, branches und tags anzulegen. Der trunk (Stamm) beinhaltet das aktuelle Arbeitsverzeichnis, dort werden alle Projektdateien nach den persönlichen Vorlieben organisiert. Damit stellt der trunk den aktuellen Projektstand dar. In tags (Markierungen) werden spezielle Markierungen während des Projektfortschritts erzeugt. Eine solche Markierung ist beispielsweise eine neue Version der Anwendung. Branches (Verzweigungen) stellen parallele Entwicklungsstränge dar. Das ist meist dann der Fall, wenn eine Version abgeschlossen ist und nach einer Auslieferung weitergepflegt wird. Eine Weiterentwicklung von abgeschlossenen Versionen ist in der Regel dann notwendig, wenn nachträglich Fehler bekannt werden, die direkt behoben werden müssen, noch bevor eine neue Version ausgeliefert werden kann. Damit die Änderungen anschließend auch in der neuen Version verfügbar sind, können beide branches mit einem Merge zusammengeführt werden. Der besondere Vorteil von SVN gegenüber CVS ist die effiziente Art, wie die Verzweigungen und Markierungen gespeichert sind. Subversion erzeugt dafür keine physische Kopie, sondern nutzt Verlinkungen zum Hauptentwicklungsstrang.

Nachträgliche Manipulationen am Repository

Nach einem erfolgreichen Commit lassen sich mit der Standardeinstellung keine Änderungen mehr vornehmen. Wenn Logmeldungen nach dem Commit bearbeitet werden sollen, ist es notwendig, einige Veränderungen vorzunehmen. Dazu wechselt man in den Ordner hooks des betreffenden Repositories. Dort wird die Datei pre-revprop-change.bat mit dem folgenden Inhalt angelegt:

if “%4“ == “svn:log“ exit 0
echo Eigenschaft ‘%4‘ kann nicht geändert werden >&2
exit 1

Das Listing ermöglicht es, die Logmeldungen im Nachhinein noch zu ändern. In hooks können verschiedene Skripte abhängig zu den Aktionen gesteuert werden.

Erste Schritte mit SVN

Um die Projektstruktur in das Repository übertragen zu können, müssen die Ordner und Dateien zuerst im Dateisystem angelegt werden. Sobald das geschehen ist, kann der erste Commit ins Subversion erfolgen. Das Senden der Daten ist als Transaktion angelegt, das bedeutet, im Fehlerfall wird die gesamte Übertragung verworfen. Nur wenn alle Dateien erfolgreich übermittelt worden sind, ist die Änderung erfolgreich. Um einen Import auszuführen, muss auf das Root-Verzeichnis mit den zu übertragenden Dateien navigiert werden. Nun kann mit einem Rechtsklick auf den Hauptordner die Option TortoiseSVN/Import ausgewählt werden. Im Importdialog muss nun der URL zum Projektarchiv angegeben werden. Wenn der Apache Web Server nach Listing 2 konfiguriert wurde, lautet die richtige Adresse http://127.0.0.1/svn/[meinProjekt]. Dazu kann noch eine Logmeldung eingetragen werden.

Der Erfolg des Importierens kann wie üblich über eine Rechtsklick mit dem Eintrag TortoiseSVN/Projektarchiv kontrolliert werden. War der Import erfolgreich, kann die erzeugte Projektstruktur getrost gelöscht werden und es steht der erste Checkout aus dem Projektarchiv an. Dazu wird an die gewünschte Position im Dateisystem gewechselt und dort mit Rechtsklick der Eintrag SVN Auschecken genutzt. Damit nun nicht das gesamte Repository heruntergeladen wird, sondern nur der aktuelle Projektfortschritt, muss der Download-URL um das Verzeichnis trunk erweitert werden. Die übertragenen Dateien werden als lokale Arbeitskopie bezeichnet und sind

Abb. 2: Funktionsumfang des TortoiseSVN-Clients

Der Screenshot in Abbildung 2 zeigt die typischen Funktionen von TortoiseSVN, die stets mit einem Rechtsklick erreicht werden. Das Kontextmenü unterscheidet bei einer Selektion zwischen Dateien und Verzeichnissen. Bei nichtversionierten Verzeichnissen stehen die Optionen Hinzufügen, Importieren und Ignorieren zur Auswahl. Wenn die Optionen gleich nach der Aufnahme neuer Dateien in die lokale Arbeitskopie gesetzt werden, sind spätere Falschübertragungen bei einem Commit wesentlich geringer. Durch die Verwendung solcher Markierungen werden stets die richtigen Dateien für die Übertragung vorselektiert, und einem falsch gesetzten Haken unter Zeitstress ist so einfach vorzubeugen.

Jeder Commit in das SVN lässt eine interne Revisionsnummer um eins erhöhen. Die letzte übermittelte Revision wird als HEAD bezeichnet und stellt immer den aktuellen Stand dar. Um auf frühere Versionen des Projekts zugreifen zu können, wird diese Revisionsnummer benötigt. Über die Logmeldungen lässt sich nachvollziehen, welche Änderung in einer Revision gemacht wurde. Es ist somit möglich, jederzeit eine bestimmte Revision aus dem Projektarchiv auszuchecken. Bei sehr vielen Revisionen kann die interne Suchfunktion des Clients verwendet werden, um bestimmte Schlüsselwörter in den Logs zu finden. Dies ist auch ein Grund, von vornherein mit Weitblick sinnvolle Beschreibungen zu finden. Eine Logmeldung sollte die Art der Änderung, die betroffenen Funktionen und eine kurze Beschreibung beinhalten. Ein Beispiel für eine solche Meldung ist: >>FEATURE: Kalender – Berechnung Ostersonntag hinzugefügt.<<

Revision oder Version?

Wichtig im Umgang mit einer Versionsverwaltung ist die Unterscheidung der Begriffe Build und Version. Ein Build ist ein einzelner Iterationsschritt, welcher der erstellten Anwendung nur eine einzige neue Funktion, beziehungsweise ein Feature hinzufügt. Ein Build ist mit der Revisionsnummer im SVN gleichzusetzen. Die Version einer Software ist eine Zusammenstellung verschiedener Funktionen und Features. Erst wenn die geforderte Funktionalität einer Version implementiert ist, erfolgt das Erhöhen der Versionsnummer. Die Version besteht also aus mehreren Builds.

In manchen Fällen ist es wichtig, im Repository Dateien gegen Veränderungen zu sichern. Dafür kann der Mechanismus Sperre holen und Sperre freigeben benutzt werden. Solange Dateien gesperrt sind, können sie nicht durch einen Commit verändert werden. Das beugt Konflikten vor, die entstehen, wenn eine Datei gleichzeitig editiert wird. Um Unterschiede in den Revisionen einer Datei zu erkennen, steht ein so genannter Diff zur Verfügung. Die Abbildung 3 zeigt einen solchen Diff. Es wird immer der Unterschied der aktuellen Arbeitskopie zur vorhergehenden Revision angezeigt. Tortoise lässt sich auch mit dem freien Tool WinMerge kombinieren, um weitere Funktionen zum Dateivergleich zur Verfügung zu haben. Das ist besonders dann interessant, wenn mehrere Revisionen einer Datei verglichen werden müssen. Dazu muss nicht immer das ganze Projekt ausgecheckt werden, es genügt durchaus, nur die betreffenden Files herunterzuladen.

Abb. 3: Diff-Ansicht des Tortoise-Clients

Markieren und Verzweigen

Abb. 4: Verzweigen/Markieren-Dialog

Eine Markierung stellt einen semantischen Zusammenhang des Projektfortschritts zu einer Revisionsnummer im Repository dar. Um das Repository übersichtlich zu halten, werden nur vorher festgelegte Revisionen getaggt. Eine solche Revision kann beispielsweise der Sprung auf eine neue Version der eigenen Applikation sein oder ein Upgrade eines verwendeten Frameworks auf eine aktuelle Version. Wenn einmal eine Markierung nicht sofort angelegt wurde, ist dies auch nicht problematisch. Tags können jederzeit auch aus jeder beliebigen Revisionsnummer erzeugt werden. Daher ist es unproblematisch, nach mehreren Commits die gewünschte Revision im Nachhinein zu taggen. Um eine Markierung zu erzeugen, wird der Eintrag Verzweigen/Markieren im Kontexmenü benutzt. Dazu ist es wichtig, auch im Root-Ordner des gesamten Projekts zu sein, da sonst nur Teile getaggt werden. In Abbildung 4 ist der betreffende Dialog dargestellt. An der ersten Position ist das Quellverzeichnis angegeben. Im Eingabefeld Zu URL wird der Pfad von trunk nach tags korrigiert. In tags ist es notwendig, den Pfad mit einem neuen Ordner zu erweitern, der z. B. die Versionsnummer als Namen besitzt. Wenn der Pfad des trunks nicht erweitert wird, kommt es zu einer Fehlermeldung und der tag wird nicht angelegt. Als Nächstes wird die Auswahl getroffen, welche Revision verwendet werden soll. Zu guter Letzt darf natürlich auch eine Logmeldung nicht fehlen. Wenn nun das Projektarchiv geöffnet wird, ist im Verzeichnis tags ein neuer Ordner angelegt, der sämtliche Projektdateien zu einem bestimmten Revisionsstand enthält. In tags werden keine Änderungen übertragen.

Für Verzweigungen wird analog vorgegangen, nur dass das Verzeichnis tags durch branches ersetzt werden muss. Bei der späteren Arbeit mit Entwicklungszweigen, die vom trunk abweichen, muss der Commit auch stets in das entsprechende Unterverzeichnis von branches übertragen werden. Das Zusammenführen eines branchs mit der HEAD-Revision des trunks erfolgt über das Kontexmenü. Die vorhandenen Konflikte müssen von Hand über den Diff-Betrachter aufgelöst werden.

Fazit

Wie zu erkennen ist, handelt es sich bei Subversion um ein sehr leistungsfähiges Werkzeug, dessen Leistungsspektrum von diesem Artikel nur angerissen werden konnte. Eine ausführliche Abhandlung zur Theorie und weiterführende Konzepte mit Subversion sind im SVN Book zu finden.