12.12. Javascript Metriken

Metriken allgemein

Im IEEE-Standard 1061 sind Softwaremetriken wie folgt beschrieben:

“Eine Softwaremetrik ist eine Funktion, die eine Software-Einheit in einen Zahlenwert abbildet. Dieser berechnete Wert ist interpretierbar als Erfüllungsgrad einer Qualitätseigenschaft der Software-Einheit.”

Jetzt stellt sich die Frage: Wozu benötigen wir Softwaremetriken überhaupt? Diese Frage lässt sich relativ leicht beantworten: Metriken werden benötigt, um Software und deren Qualität messbar zu machen. Hat man nun diese konkreten Werte vorliegen, kann man die Produkte verschiedener Anbieter anhand bestimmter Kriterien miteinander vergleichen, um eine Kaufentscheidung zu erleichtern. Ein weiterer Anwendungsfall für Softwaremetriken ist, dass sich mit ihnen der aktuelle Stand eines Projekts dokumentieren lässt. Werden Metriken über einen längeren Zeitraum gesammelt, erlauben sie Rückschlüsse auf die Entwicklung in einem Team und einem Projekt.

Das Thema Softwaremetriken ist nicht wirklich neu und auch nicht sonderlich spektakulär. Softwaremetriken sind seit vielen Jahren der Gegenstand von Forschung an verschiedensten Universitäten und damit sowohl praktisch als auch theoretisch sehr gut dokumentiert. Die Probleme treten allerdings schon auf, wenn man den ersten Schritt von der Theorie in die Praxis wagt: Für welche Programmiersprachen stehen welche Metriken zur Verfügung?

Etwas Recherche im Internet zeigt, dass es für Java, C und C++ Werkzeuge zur Erfassung von Softwaremetriken wie Sand am Meer gibt. Diese Tatsache ist allerdings auch nicht weiter verwunderlich, da die Forschungsarbeiten in erster Linie auf diesen Sprachen aufbauen und auch die Notwendigkeit eines lückenlosen Qualitätsmonitorings in diesen Bereichen in großem Maß vorhanden ist.

In unserer täglichen Arbeit sind Metriken im PHP Umfeld relevant. Auch hier existiert ein Satz an Werkzeugen, der die wichtigsten Metriken erfasst. Eine Anforderung an Messwerkzeuge ist, dass diese für den Entwickler keinen unnötigen Aufwand verursachen und die Metriken automatisiert erzeugt werden. Zu diesem Zweck generieren Werkzeuge wie beispielsweise phpunit, phpmd und phpcs Ausgaben in xml und lassen sich damit in eine Continuous Integration Plattform wie Jenkins integrieren. Ist dies erreicht, werden die Werkzeuge bei jedem Commit ins Versionskontrollsystem ausgeführt und es stehen allen am Projekt Beteiligten detaillierte Informationen über die Qualität des Quellcodes zur Verfügung.

Javascript Metriken

Da Javascript zunehmend an Bedeutung in der Entwicklung von Webapplikationen gewinnt, besteht auch hier Bedarf an Qualitätssicherung. Um eine möglichst hohe Qualität im Bereich Javascript durchzusetzen, müssen einige Voraussetzungen erfüllt sein. Das Wichtigste, was hier zu nennen wäre, ist die strikte Trennung von Darstellung und Logik. In der Praxis bedeutet dies: HTML stellt die Struktur der Seite und deren logischen Aufbau dar, CSS wird für die Darstellung und das Layouting verwendet und Javascript beinhaltet die Frontendlogik. Diese drei Bereiche sollten strikt getrennt und in jeweils eigenen Dateien abgelegt werden. Durch dieses Vorgehen können die einzelnen Teilaspekte unabhängig voneinander betrachtet werden.

LOC Metriken

Die einfachste Kategorie von Metriken, die in Javascript zur Verfügung stehen, sind die sogenannten LOC-Metriken (Lines of Code). Bei diesen Metriken werden die Zeilen des Quellcodes gezählt. Ein Tool, mit dem diese Metriken erfasst werden können, ist CLOC. Hier wird neben der reinen Anzahl an Zeilen unterschieden zwischen eigentlichen Codezeilen, Kommentaren und Leerzeilen und auf wie viele Dateien diese verteilt sind.

In Verbindung mit Konventionen, die für das Projekt vereinbart werden, wie beispielsweise die maximale Zeilenlänge oder höchstens ein Statement pro Zeile, machen LOC Metriken Sinn.

Unittests

Einen weiteren Satz von Werkzeugen bilden die Unittest-Frameworks. Unittests werden verwendet, um Bausteine von Software, die sogenannten Units, zu prüfen. Voraussetzung, um Unittests zu erstellen, ist eine sinnvolle objektorientierte Architektur der Anwendung.

Die erste Metrik, die für Unittests zur Verfügung steht, ist die Anzahl der Tests. Diese kann von einigen wenigen Tests bis hin zu mehreren Tausenden reichen. Die Zahl der Tests für sich gesehen ist allerdings kein Qualitätsmerkmal. Pro Unit, die getestet wird, sollten mehrere Tests existieren. Die minimale Anforderung ist ein Test für den positiven Fall und einer für den Fehlerfall. Je nach Logik in der Einheit, kann es sein, dass mehrere Fälle abgetestet werden müssen, um sicherzustellen, dass die gewünschte Funktionalität reibungslos abläuft.

Als Framework für die Unittests kann beispielsweise qunit verwendet werden. Ursprünglich entstand dieses Werkzeug für die Qualitätssicherung von jquery, kann allerdings unabhängig davon verwendet werden. Zur Automatisierung und Integration in eine Continuous Integration Plattform wie Jenkins wird jsTestDriver verwendet. Für dieses Tool existiert ein Adapter, der bestehende qunit Tests in jsTestDriver lauffähig macht.

Die Qualität von Unittests lässt sich kaum messen. Das einzige Mittel, das eine Aussage über die Qualität der Tests erlaubt, ist die Testabdeckung. Die Testabdeckung beschreibt, wie viel des Quellcodes wirklich durch die Tests abgedeckt ist, also, ob alle if-Statements berücksichtig sind und ob sämtliche Cases in Switch-Statements geprüft werden. Eine Testabdeckung von 100% bedeutet, dass sämtlicher Quellcode durch die Unittests einmal ausgeführt wurde. Aber auch eine hundertprozentige Testabdeckung stellt nicht sicher, dass sämtliche Kombinationen der Applikationslogik geprüft werden. Hier ist es notwendig, dass sich die Entwickler Gedanken über die auftretenden Fälle machen, Testpläne erstellen und diese gezielt durch Unittests absichern.

Jetzt kommen wir zu einem Werkzeug, das in keinem Javascript-Projekt fehlen darf: jslint. Dieses Programm durchsucht den Quellcode nach möglichen Problemen. Hierunter fallen sowohl die korrekte Einrückung des Quellcodes, als auch ein Komma zu viel am Ende einer Arraydefinition oder Zuweisungen in if-Statements statt einem logischen Operator.

Jslint

Jslint ist sowohl über ein Webformular als auch offline verfügbar. Da die Implementierung vollständig in Javascript erfolgte, ist es problemlos möglich, dieses Tool auf jedem Rechner über die Kommandozeile auszuführen, man benötigt lediglich eine Javascript Engine.

Im alltäglichen Gebraucht hat es sich als praktisch erwiesen, jslint als Pre-Commit Hook einzubinden und jeden Commit abzuweisen, der fehlerhaftes Javascript beinhaltet. Mit jslint4java generiert jslint xml-Ausgaben und kann damit auch in eine Continuous Integration Plattform wie Jenkins integriert werden.

CPD und Komplexität

Einen Schritt weiter geht das Javascript Plugin für die Qualitätsmanagement Plattform Sonar. Mit diesem Plugin werden neben den Prüfungen von jslint auch Codeduplikation und Komplexität gemessen.

Doppelter Code ist in vielen Projekten ein Problem, da aus Gründen der Zeitersparnis einfach Code kopiert wird und nicht sauber ausgelagert und von verschiedenen Stellen referenziert wird. Die Copy-Paste-Detection vergleicht allerdings nicht Codeblöcke Wort für Wort miteinander, sondern auf Ebene des Abstract Syntax Trees. Es nützt also nichts, einfach nur Variablen umzubennen oder Whitespaces einzufügen.

Zur Bewertung der Komplexität benutzt das Sonar Javascript Plugin die zyklomatische Komplexität des Quellcodes. Diese Metrik wird beeinflusst durch die Anzahl der Anweisungen und die Kontrollflüsse zwischen diesen. Weist Quellcode eine zu hohe Komplexität auf, ist er schwer zu lesen. Aus dieser Tatsache folgt ein erhöhter Wartungsaufwand und eine länger andauernde Einarbeitungsphase.

Metriken im Alltag

Zusammenfassend lässt sich sagen, dass die Qualitätssicherung im Bereich Javascript momentan noch in den Kinderschuhen steckt. Allerdings ist hier eine rasante Entwicklung zu beobachten. Vor allem im Bereich der Continuous Integration und Continuous Inspection ist eine erfreuliche Tendenz festzustellen. Immer mehr Werkzeuge lassen sich in Plattformen integrieren und ermöglichen so die regelmäßige Prüfung von Javascript Quellcode in einem Projekt.

Allgemein lässt sich festhalten, dass eine Metrik für sich alleine gesehen in den seltensten Fällen wirklich aussagekräftig ist. Kombinationen verschiedener Metriken oder Metrikgruppen hingegen erlauben Rückschlüsse auf die Qualität der Applikation.

Hier ein kurzes Beispiel, um diesen Sachverhalt zu verdeutlichen: Nimmt man eine Funktion, kann man über die LOC-Metrik herausfinden, aus wie vielen Zeilen diese Funktion besteht. Dieser Wert an sich erlaubt kaum eine Aussage, außer, dass eine große Anzahl von Zeilen nicht erstrebenswert ist, da sich diese Funktion dann tendenziell um mehr als eine Sache kümmert. Zieht man die zyklomatische Komplexität zu Rate, kann man schon qualifiziertere Aussagen treffen. Eine umfangreiche Funktion mit einer hohen Komplexität stellt ein Problem dar und sollte in kleinere Einheiten unterteilt werden; eine lange Funktion mit geringer Komplexität deutet auf eine prozedurale Funktion hin, die ebenfalls verbesserungswürdig ist. Sinnvoll sind demnach relativ kurze Funktionen mit moderater Komplexität.

Neben dem reinen Qualitätsaspekt kann durch Metriken auch die Performance des gesamten Teams oder einzelner Entwickler gemessen werden. Hier beginnt die Messung schon bei der Anzahl an Commits oder Lines of Code, die ein Entwickler erstellt. Auch hier gilt, jede Metrik kritisch zu hinterfragen. Interessanter sind dann Kombinationen wie beispielsweise die Anzahl der Zeilen pro Commit. Commits mit einer großen Anzahl von Zeilen sind meist problematisch, da sie dem Prinzip atomarer Commits widersprechen.

Die Metriken eines Projekts sollten allen am Projekt Beteiligten zur Verfügung stehen. Nur durch einen offenen Umgang lassen sich die Vorteile der Softwaremessung ausnutzen. Stehen dem Team alle Informationen über die Qualitätsaspekte der erstellten Software zur Verfügung, können die einzelnen Entwickler gezielt an ihren Schwächen arbeiten und das Projekt gemeinsam stabilisieren und den maximalen Nutzen aus ihren Fähigkeiten ziehen.

Links

11.12.: Migrate to HTML5!

HTML5 is one of the hottest buzzwords in the web and everyone is using or talking about it. Google is ahead everyone else for sure with Google Docs, their web based office suite and with Chrome OS, an operating system which only needs a browser (from the user‘s view). But also Facebook, they working on their own application platform codenamed „Spartacus“ is based on HTML5. Even classic software companies like Adobe and Microsoft are joining the competition: Microsofts upcoming Windows 8 operating system will include small HTML5 based apps (another buzzword) and Adobe has a double-tracked strategy: they release new HTML5 development tools almost every month and they still try to rescue their old, main product, Flash.
Weiterlesen

10.12. Lösungen für Debugging von Mobile Web Apps

Webkit Web Inspector (Remote)

Dass Firebug in JavaScript programmiert wurde dürfte den meisten bekannt sein. Das gleiche gilt für den WebInspector von WebKit, wie er in Safari oder Google Chrome zu finden ist. Es dürfte also nicht wundern, dass für mobile Geräte mit Weinre von Patrick Mueller bereits 2010 eine Portierung des WebInspectors geschaffen wurde, die über eine JS-Include auf der im Website-Header im Mobilen Browser Remote Debugging Funktionalität zur Verfügung stellt. Somit kann bequem über dem Desktop eine Mobile Webseite debugged werden. Weinre läuft heute als PhoneGap Projekt, ist sozusagen Standard und ist natürlich auf GitHub zu finden.

Das Ganze hat aber leider eben leider Grenzen, was Features wie Breakpoints, Backtraces und Profiling angeht, d.h. genau die nützlichen Features, die normalerweis unter dem “Script”-Tab im Debugger-Panel zu finden sind.

JavaScript Remote Debugging mit WebKit/Chrome

Der nächste konsequente Schritt war also, den Debugger direkt in den Browser Runtime zu heben und eine Remote API anzubieten bzw. eine Verbindung zu dem ohnehin schon existierenden V8 DebuggerProtocol zu schaffen, dass sich allerdings nur auf JavaScript Debugging beschränkt. Das Gesamtpaket nennt sich dann WebKit Remote Debugging Protocol. Währenddessen arbeitete Google auch am ChromeDevToolsProtocol was aber mittlerweile deprecated ist.

Seit Frühjahr diesen Jahres bietet nun WebKit sein Remote Debugging Feature an, welcher praktisch alle bekannten WebInspector Features unterstützt – dazu zählen:

  • JavaScript Console & JS Debugger
  • CSS Debugging & Live Änderungen
  • DOM Manipulation & Debugging – z.B. DOM Knoten auf Änderungen durch JS Events überwachen (DOM Mutation Events)
  • Netzwerk & Timeline – Verfolgung von Netzwerk-Aktivitäten auf der Seite (HTTP, WebSocket, Timings)
  • Resourcen – LocalStorage, ApplicationCache, Cookies

Das Feature kann bereits seit einigen Chrome Versionen getestet werden. Eine aktuelle Chrome Version bevorzugt kann eine Debugger-Instanz mit chrome --remote-debugging-port=9222 gestartet wird.

Sodann ist eine zweite Browserinstanz für den Remote Web Inspector nötig – diese muss jedoch Ihr eigenes Nutzerprofil verwenden, um Probleme zu vermeiden: chrome –user-data-dir=<existierendes Verzeichnis>

Mit Navigation auf http://localhost:9222 im zweiten Browserfenster findet sich nun eine Thumbnail-Übersicht der geöffneten Tabs des zu debuggenden Browsers. Ein weiterer Klick auf das ein Thumbnail lädt nun den Debugger auf die komplette Seite, mit dem wie gewohnt gearbeitet werden kann.

Somit kann zusammenfassend folgendes zur Funktionsweise gesagt werden:

  • Der Web Inspector ist eine Web Application.
  • Der Debugger Server lieftert per HTTP HTML, JavaScript wie CSS aus.
  • Sobald die Application geladen ist wird ein WebSocket zu http://localhost:9222/json geöffnet
  • Der Debugging Port ist für jeden offen, insofern nicht durch Firewall geschützt.
  • Neue Remote Debugging Sessions ersetzen evtl. bereits laufende Debug-Sessions
  • Web Inspector Remote läuft derzeit nur in WebKit Browsern einwandfrei

In iPhone oder Android-WebKits sucht man den Debugger derzeit noch vergebens (about:debug), auch wenn es bereits einige ROMs für Android mit Web Inspector Support gibt. Blackberrys Playbook hingegen besitzt schon entsprechende WebKit Funktionalität.

Der Debugger bietet für den Browser eine vereinfachte, aber noch experimentelle JavaScript API, die z.B. auch durch Chrome Extensions angesprochen werden kann. Nach Google’s Vorstellungen sollen damit auch WebIDEs wie Cloud9 zum bereits integrierten JavaScript Debugger (lib-v8debug) einen vollwertigen “WebInspector” erhalten.

Google/Webkit sind nicht die ersten

Opera demonstrierte bereits 2008 mit DragonFly und Scope einen funktionierenden Remote Debugger, mit dem es möglich ist sich an an einen Opera Mobile oder auch Desktop Opera via TCP-Port ranzuhängen und nicht nur JavaScript zu debuggen. Nachteil an der ganzen Sache: Im Mobile Web dominiert derzeit WebKit.

Firebug Crossfire

Ein ähnliches Projekt existiert seit Anfang diesen Jahres mit Firebug Crossfire, was ähnliche Möglichkeiten bieten soll. Zudem unterstützen die JavaScript Development Tools (JSDT) für Eclipse bereits Crossfire. Derzeit befindet sich das Projekt jedoch noch in der Alpha-Phase, aber darf bereits getestet werden.

Weitere JavaScript Debugging Plugins

Für den, der nodejs debuggen muss, gibt es mit dem NodeInspector eine schicke Lösung, mit der es möglich ist, dies bequem im Browser zu erledigen. NodeInspector ist wie ebenfalls wie Weinre eine Adaption von WebInspector.

Für JavaScript Debugging in der IDE, d.h. bequem Breakpoints in den Quelldateien des geöffneten Projekts setzen, haben wir zum einen die ChromeDevTools als Eclipse-Plugin. Zum anderen hat IntelliJ mit IDEA 10.5 und PHPStorm 3 das V8 DebuggerProtocol bereits implementiert.

Eine weitere einfache JavaScript-Konsole stellt z.B. JSConsole bereit, dass zum Debuggen von iPhone oder Android-Mobile Apps benutzt werden kann.

08.12. Agilere Datenbankentwicklung

Agile Entwicklung ist gescheitert.
Jedenfalls auf Datenbankseite.

Agile Entwicklung ist mehr als nur Scrum, hierzu kommen in den meisten Projekten noch weitere Tools und Vorgehensweisen zum Einsatz, um schnell auf neue Anforderungen zu reagieren.
Hierzu zählen in der eigentlichen Entwicklung Continuous Improvements, also das stetige Verbessern des Quellcode innerhalb eines Projektes, welche zum Beispiel durch Code Reviews und Refactorings unterstützt werden können.

Bedingt durch die sich schnell ändernden Anforderungen ändert sich auch der Code schneller und häufiger.
Um sich dennoch abzusichern, kommen hier Tools wie automatisierte Unittests, ausgeführt Beispielsweise in einer Continuous Integration Umgebung zum Einsatz.

Inzwischen haben viele Projekte zudem erkannt, dass die kurzen Entwicklungszyklen, die mithilfe, eben genannter Techniken möglich werden, entsprechend kurze Releasezyklen erfordern.
Im Idealfall führt dies zu einem Continuous Deployment, also der Fähigkeit ein Feature sofort nach der Fertigstellung zu releasen.

Ein Prozess ist jedoch immer nur so gut, wie seine Teilprozesse.
An dieser Stelle sollten wir unseren Blick auf die Datenbank lenken.

  • Wie läuft hier die Entwicklung?
  • Wie automatisieren wir Datenbankupdates?
  • Was für einen Stand hat unsere Datenbank auf Produktiv? Auf Staging? Auf dem Previewsystem?
  • Wie sichern wir Datenverluste bei nachträglichen Änderungen ab?

Bei uns lief es im Projekt bis vor kurzem so, dass vor einem Update der Datenbank händisch geprüft werden musste welche Änderungen noch nicht in der Datenbank existieren um dann entsprechende SQL Dateien zusammenfügen zu können, die die neuen Änderungen enthielten.
So ein Vorgehen ist nicht nur Fehleranfällig sondern auch Aufwendig.
Am stärksten Bemerkbar machte sich dies, beim migrieren von Daten, was bedeutete, dass die Reihenfolge von SQL Dateien und Migrationsskripten strikt beachtet werden musste.

Refactorings hingegen liefen so ab, dass die neue Datenstruktur in Form von neuen Tabellen angelegt wurde, die Daten mithilfe von Migrationsskripten überführt wurden und die ursprünglichen Tabellen erst beim nächsten Release vollständig gelöscht wurden, sofern dies nicht vergessen wurde.

Dieses Vorgehen kostete viel Zeit und Nerven, weshalb eine Alternative gesucht wurde.

Vor kurzem haben wir als Team ein neues Tool gefunden welches uns viel Arbeit abnimmt und vor allem zusätzliche Sicherheit auf Datenbankseite gibt.

Dies ist Liquibase, ein in Java geschriebenes Tool zum Refactoring und automatischen Update der Datenbank, welches unter der Apache 2.0 Lizenz zur freien Nutzung zur Verfügung steht.

Liquibase bringt eine eigene Beschreibungssprache für Datenbankänderungen mit, die auf XML basiert.
Durch diese abstrakte Beschreibung der Änderungen in XML wird Datenbankunabhängigkeit ermöglicht.
So kann Liquibase mit jeder Datenbank umgehen für die ein JDBC Treiber verfügbar ist, so zum Beispiel MySQL, Microsoft SQL Server, Oracle, PostgreSQL, SQLite, Apache Derby und vielen weiteren.

Definiert werden die Änderungen als sogenannte Changesets, die in beliebiger Anzahl innerhalb eines DatabaseChangelogs vorkommen können.
Jedes Changeset setzt die Angabe eines Autors und einer Id voraus, wobei die Id nur innerhalb des DatabaseChangelogs eindeutig sein muss.

Ein einfaches Changelog, der eine einzelne Tabelle mit 2 Spalten, id und name, anlegt sieht wie folgt aus:

 	
	        				
		            		
			                			
				            		
			            		
			                					
				            		
			            	
		    
	

Ausgeführt werden kann dieses Changelog entweder innerhalb eines vorhandenen Buildsystems, hierfür gibt es Tasks in ANT, Maven, Grails, Spring und in Phing als Erweiterung unter https://github.com/bitExpert/liquibase-phing, oder über die Kommandozeile:

java -jar liquibase.jar \
    --driver=com.mysql.jdbc.Driver \     
    --classpath=databasedriver/mysql-connector-java-5.1.17-bin.jar \     
    --changeLogFile=/path/to/changelog.xml \     
    --url="jdbc:mysql://127.0.0.1:3306/" \     
   --username= \     
   --password= \     
update

Bei diesem Aufruf wird der Treibertyp, in unserem Fall JDBC MySQL, das Verzeichnis des Treibers, der Pfad zum auszuführenden Changelog, sowie URL der Datenbank, Nutzername und Passwort angegeben und der Befehl update, um Liquibase zu veranlassen, dass alle Änderungen eingespielt werden, die noch nicht in der Datenbank sind.
Am Rande sei hier bemerkt, dass der JDBC Treiber für die jeweilige Datenbank nicht Teil von Liquibase ist, ergo separat heruntergeladen werden muss.

Wer sich jetzt fragt, woher Liquibase wissen kann, was bereits in der Datenbank vorhanden ist und was geupdatet werden muss, dem möge folgende kurze Erklärung dienen:
Liquibase speichert in der Tabelle DATABASECHANGELOG Metainformationen zu jedem erfolgtem Update ab.
Hierzu gehört für jedes ausgeführte Changeset der Autor, die Id, das Ausführungsdatum und eine Hashsumme des Changesets.
Die Hashsumme wird bei jedem neuen Update für alle bereits vorhandenen Changesets geprüft, so dass nachträgliche Änderungen an einem bereits ausgeführten Changeset nicht mehr möglich sind.
Es gibt zwar die Möglichkeit mit dem Kommandozeilenbefehl clearChecksums alle Hashsummen zu löschen, jedoch ist die saubere Vorgehensweise bei einem Fehler ein neues Changeset anzulegen, welches den Fehler behebt.

Der größte Vorteil, den man mit echten Changesets gewinnt, sind die Rollbacks.
Für alle Änderungen die neue Tabellen, Spalten oder ähnliches anlegen, oder bestehende Verändern, bietet Liquibase automatische Rollbacks.
Diese werden wichtig, sobald beim updaten etwas schief geht, denn dann wird der Rollback ausgeführt, so dass eine inkonsistente Datenbank verhindert wird.
Jedoch sind die Rollbacks auch in der Entwicklung sehr nützlich, da jederzeit zu einem bestimmten Stand der Datenbank zurück gekehrt werden kann.
Dies ist Changesetabhängig möglich, mit rollbackCount n, welches die letzten n Changesets zurück nimmt, Datumsabhängig mit rollbackDate <date>, welches alle Changesets die neuer als das angegebene Datum sind zurück nimmt und Tag abhängig.
Letzteres kehrt dabei zu einem in Liquibase gesicherten Stand der Datenbank zurück, einem sogenanntem Tag.

Für alle Rollbacks, die nicht mit einem Automatismus abgedeckt werden, kann auch manuell ein Rollback definiert werden.
Dies ist zum Beispiel der Fall wenn das Löschen einer Tabelle fehlschlägt und darauf entsprechend reagiert werden soll.
Das Definieren geschieht innerhalb des entsprechenden Changesets, indem nach der eigentlichen Anweisung eine oder mehrere Rollbackanweisungen geschrieben werden, die alle innerhalb des Tags <rollback> stehen müssen.

In den meisten Teams ist Dokumentation nicht gerade beliebt, jedoch ein notwendiges Übel um neuen Teammitgliedern den Einstieg zu erleichtern und nachvollziehbar zu machen, welche Änderungen wann gemacht wurden.
Auch hier Unterstützt uns Liquibase.
Mit dem Befehl dbDoc und einer nachfolgenden Pfadangabe ist es möglich, eine Dokumentation aller Änderungen zu generieren, die mit dem angegebenen DatabaseChangeLog durchgeführt werden würden.
Die dabei entstehende Änderungsdokumentation ist dabei stark an Java-Doc angelehnt.

Am meisten Zeit bei der Datenbankentwicklung mit Liquibase verschlingt das Schreiben der Changesets.
Zum Glück stellt auch hier Liquibase ein Tool bereit.
Die Methode diffChangeLog generiert anhand der Unterschiede zwischen zwei Datenbanken die entsprechenden Changesets.
Der Kommandozeilenaufruf dazu sieht ähnlich aus, wie beim updaten der Datenbank, jedoch werden zusätzlich die Daten der zweiten Datenbank angegeben, gegen welche geprüft wird:

java -jar liquibase.jar     \
	[...]    
	--changeLogFile=../data/sql/generatedChangelog.xml     \
	diffChangeLog   \  
	--referenceUrl=  \   
	--referenceUsername= \     	
	--referencePassword=

Die neuen Changesets werden im angegebenen changeLogFile gespeichert.
Dabei werden sowohl Stored Procedures und Functions, als auch Trigger und Check Constraints ignoriert.

Die Unterschiede können mit Liquibase auch zwischen verschiedenen Datenbanksystemen ermittelt werde, beispielsweise einer MySQL und einer SQLite Datenbank.

Auch wenn die Einarbeitung in Liquibase einige Zeit erfordert und vor allem eine Umstellung in der Arbeitsweise, so möchte ich dieses geniale Tool im täglichen Arbeiten nicht mehr missen, da uns als Team damit viele Sorgen und Mehraufwände abgenommen werden.

07.12. One-click Deployment

Today’s topic is deployment. It’s called one-click deployment for a reason: Developers are lazy.
It’s hard to do less than clicking on one button, so that’s our goal.

With the growing need for lower time-to-market and faster response to user feedback it is inevitable to not be limited by technical factors (there are enough other obstacles already). The focus lies on reproducible results.

Weiterlesen

06.12. Doctrine 2 – Zend Framework Integration

In yesterday’s article of our advent calendar, we explained the concepts underlying Doctrine 2. In today’s article, we want to use that knowledge and create a simple Zend Framework (ZF) application that uses Doctrine 2 to persist its business objects.

While explaining how to integrate Doctrine 2 into Zend Framework, we will create a generic sandbox that can be used for future projects building up on these technologies.

Weiterlesen

Domain-Driven-Design – Vortrag@Mayflower-Würzburg

Am kommenden Donnerstag, den 08.12.2011 findet ein weiterer öffentlicher Vortrag im Mayflower-Büro in Würzburg statt (ACHTUNG: wir sind umgezogen! NEU: Gneisenaustraße 10/11, 97074 Würzburg, Bushaltestelle Barbarastraße mit der Linie 28).

Beginn ist um 18:00 Uhr, Thema des Vortrags ist „Domain-Driven-Design„.

Aco Mitevski erklärt anhand eines kleinen Beispielprojektes wie man Domain-Driven-Design mithilfe des Zend Frameworks und Doctrine2 betreiben könnte.

Die „Donnerstags-Vorträge“ werden sowohl in Würzburg als auch in München gehalten. Bei Interesse einfach das Blog beobachten, um auf dem Laufenden zu bleiben!

Wir freuen uns auf viele Teilnehmer!

Anfahrt Büro Würzburg