Beiträge mit tag "Continuous Integration

Continuous Integration mit Jenkins

0

Am 17.Oktober zieht es mich zusammen mit Holger Rüprich nach Hamburg auf die web DevCon. Holger wird dort einen Vortrag zum Thema „Mobile Web Apps – Wie, Warum, Womit?” machen, den wir im Büro letzten Freitag schon hören durften.

Und auch ich werde dort einen Vortrag halten, und im Vergleich zu meinen letzten Talks wieder mal etwas technischer werden. Mein Vortrag behandelt das Thema Kontinuierliche Integration am Beispiel von Jenkins und PHP.

„Kontinuierliche Integration“ ist ein Prozess, der nach dem Einchecken von Code jedes Mal das komplette System neu erstellt. Selbst wenn eine Technologie keinen separaten Kompilierungsvorgang benötigt (etwa PHP), lohnt sich dennoch der Einsatz eines CI-Systems. Lassen sich doch so auch automatisiert Tests überprüfen und Fehler fallen besonders schnell auf. Jenkins ist einer der populärsten CI-Server und unterstützt zahlreiche Sprachen und Technologien wie Java, .NET oder PHP. Der Vortrag beschreibt Einrichtung und Einsatzmöglichkeiten von Jenkins und wartet mit vielen Tipps und Tricks direkt aus der Praxis auf.

Nachdem ich gerade erst von der WebTech Conference zurück bin, ist mein Plan, dieses Jahr mal alle Konferenzen links liegen zu lassen, irgendwie nicht aufgegangen.

Webinale / IPC 2010 in Berlin

0

Eine PHP Konferenz in Berlin war für mich die ideale Kombination, endlich mal wieder meinen Koffer zu packen, in einen Zug zu sitzen und mich vier Tage in einem Hotel mit einer Menge Entwickler aufzuhalten.

Berlin fand ich spitze, aber da das hier kein Blog über Städtereisen ist, schreibe ich heute „nur” eine kurze Zusammenfassung dessen, was ich mit Nico und Frank auf der International PHP Conference Spring Edition 2010 und der Webinale 2010 erlebt und gelernt habe.

Die Workshops

Begonnen hat die Konferenz für mich mit einem Workshop am Sonntag nachmittag (morgens hatten wir eine Stadtrundfahrt, aber dazu wollte ich ja hier nichts schreiben). Der Workshop „Softwarearchitektur vs PHP” von Johann-Peter Hartmann war sehr unterhaltsam und mit der Vorstellung von ATAM (Architecture Tradeoff Analysis Method) habe ich auch etwas neues gelernt. Ich hatte zwar mit etwas mehr Inhalten zum Thema Architektur gerechnet und hätte auf den interaktiven Teil auch verzichten können, aber alles in allem war es ein interessanter Vortrag.

Montag

Der Montag startet mit zwei eher durchwachsenen Keynotes: Während der Vortrag „Die Mensch-Maschine-Beziehung und ihre Folgen” von Ibrahim Evsan unterhaltsam war, obwohl er nichts Neues erzählt hatte, war die Google-Keynote „Die Zukunft liegt in der Cloud” einfach nur langweilig. Der Gipfel war, dass Petra Sonnenberg zeigen wollte, wie in Zukunft alle unsere Applikationen in der Cloud laufen, gleichzeitig aber eine Präsentation mit Google Docs erstellt hatte, die aussah wie die ersten Gehversuche mit Power Point. Geendet hat die Keynote mit einem Werbevideo von Google. Nicht gerade das, was ich mir von einem Unternehmen wie Google versprochen hatte.

Danach kam das Highlight des Tages: Julian Koschwitz hat in seiner Session zu „Augmented Editorial Design” gezeigt, wie man klassische Printmedien mit dem Web verbinden kann und Magazine um dynamischen Content wie Videos oder Sound anreichern kann. Eine Webcam und ein Browser ist ausreichend. Ähnlich gut war die erste Session der IPC, die ich danach besucht habe. David Soria Parra hat sehr anschaulich dargestellt, wie „Git für Fortgeschrittene” Probleme beseitigt, die viele von uns mittlerweile mit Subversion haben.

Nachmittags ging es mit einem Vortrag zu „Continuous Integration und Continuous Deployment” von Manuel Pichler weiter, von dem ich mir auch mehr erhofft hatte. Manuel hat die zwar Bewegründe für CI und wie man es schrittweise einführt schön zusammengefasst, der Teil über Deployment ist leider sehr kurz ausgefallen und war für mich leider nicht hilfreich, da wir täglich und nicht nur wöchentlich deployen.

Abgeschlossen habe ich den Tag mit der für mich langweiligsten Session der Webinale: „Positive User Experience durch User Centered Web Design”. Meine Experience war in diesem Vortrag nicht sehr positiv, was zum Teil auch an der fortgeschrittenen Uhrzeit gelegen haben mag.

Dienstag

Der Dienstag morgen begann mit einem Vortrag zu „Frontend Performance mit PHP” von Frank und Nico, der sehr gut besucht war und mir auch noch ein paar neue Impulse gegeben hat, obwohl ich natürlich wußte, was auf mich zu kommt.

Da sich Jung von Matt für die aktuelle 1&1 Kampagne verantwortlich zeigt, habe ich mir danach die Session „Künftig entscheidend für den Erfolg (fast) jeder Marke: Produktinfo und -inszenierung” von Michael Behrens angeschaut. Die Beispiele, die er gezeigt hat, waren interessant, jedoch weit weg von dem, was JvM für 1&1 macht. Deutlich cooler waren auch die Beispiele, die Michael Chaize in seiner Session „Ten Innovative Projects for the Flash Platform” gezeigt hat. Von 3D-Grafiken über Gesichtserkennung bis hin zur Emulation von Spielekonsolen war da für jeden was dabei. Flash scheint (leider) trotz HTML5 immer noch nicht tot zu sein.

Durch das ständige Vertauschen von Sessions habe ich leider mittags einige Sessions verpasst und die Zeit genutzt, was für’s Büro zu programmieren. Abgeschlossen habe ich den Tag mit einer spontanen Session zu YQL von Yahoo!, in der leider nur die Standard-Beispiele gezeigt wurden.

Mittwoch

Den Mittwoch habe ich nach dem Hotel-Checkout wieder mit zwei Keynotes auf der Webinale begonnen. David Carr hat in seiner Keynote „The Speed of Now” den Namen zum Programm gemacht und ist extrem schnell durch eine Masse an Slides gegangen, so dass man ihm kaum noch folgen konnte. Ossi Urchs Keynote „Social Web oder Die neue Macht der Nutzer” klang eher nach einer Keynote von 2008 als nach einer Keynote in der man Trends für 2011 erfahren hätte. Das allgegenwärtige „Twitter, Facebook und Smartphones beherrschen unser Leben!” wurde am dritten Tag der Webinale dann doch etwas alt.

Danach fand die Panel Diskussion „Holy Code, holy Shit! – Die Developer-Designer-Hölle” statt, an der ich auch beteiligt war. Leider war es organisatorisch nicht möglich, dass sich alle Teilnehmer vorher treffen, so dass hier keine wirkliche Diskussion entstand und es eher bei „Thema verfehlt” einzuordnen war. Sollte ich jemals wieder an einer Panel-Diskussion teilnehmen, dann nur, wenn es vorher auch möglich ist, sich mit den anderen Teilnehmern und vor allem dem Moderator abzustimmen.

Nach der Mittagspause war ich dann mit meinem Vortrag „23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten” dran.

Der Vortrag lief gut, ich habe mir auch meinen „Cowboy/Indianer”-Witz merken können und das Feedback war durchweg positiv. Abgeschlossen habe ich den Tag mit einem Vortrag von Frank zum Thema „A better Approach for File System dependent tests”, in dem Frank sein Projekt vfsStream vorgestellt hat.

Zusammenfassend hat sich der Besuch der Konferenzen für mich mehr gelohnt, als das in den letzten Jahren der Fall war. Tatsächlich habe ich während der Konferenz jedoch festgestellt, dass mich die Themen der Webinale mittlerweile mehr fesseln als die Sessions auf der PHP Conference.

In case of emergency…

0

Entwickler sind Menschen. Fehler passieren. Und wenn Entwicklern ein Fehler passiert, dann nennt man das Bug.

Das in einem Projekt nach dem Release nochmal Bugs auftreten, ist nicht wahrscheinlich, es ist absolut sicher. Meist haben diese Bugs dann eine (negative) finanzielle Auswirkung, oder zumindest ist das die Vermutung des Kunden. Der Kunde befürchtet einen Verdienstausfall, der natürlich so kurz wie möglich gehalten werden muss; und das rationale Denken beim Kunden, Manager und Entwickler setzt leider allzu häufig aus.

Die pragmatischen Programmierer Andrew Hunt und David Thomas haben einige Tipps, wie man sich bei der Fehlersuche verhalten sollte:

Lösen Sie das Problem, nicht die Schuldfrage.

Der Bug ist bereits aufgetreten, es wird Ihnen jetzt nichts helfen, wenn Sie wissen, wer Schuld daran ist. Leider ist es oft viel einfacher, rauszufinden, wer schuld ist, als rauszufinden, wie der Bug gefixt werden kann. Deshalb tendieren viele Menschen eher zur ersten Alternative. Was man dagegen tun kann, habe ich bereits in „Denk positiv!” geschrieben.

Wenn Sie auf Grund von Verträgen oder SLAs wissen müssen, wer die Schuld trägt, so ist für die Klärung dieser Frage nach Beseitigung des Fehlers noch genug Zeit.

Keine Panik!

Wenn man so schnell wie möglich versucht, den Bug zu fixen, ohne genauer darüber nachzudenken, ist die Gefahr groß, dass weitere Bugs ins System eingeführt werden, während einer behoben wird. Und natürlich fügen diese Bugs Ihrem Kunden meist einen noch größeren Schaden zu, als der ursprüngliche Bug.

Das absolute Highlight ist, dass in solchen Situationen gerne auch die Unit-Tests (die Folgefehler entdeckt hätten) vor dem Deployment übersprungen werden, um den Fix möglichst schnell live zu bekommen. Näher werden Sie Kamikaze in Ihrem Leben wahrscheinlich nicht kommen. Ich selbst war leider schon so nahe dran.

Bleiben Sie also ruhig und stellen Sie sicher, dass Sie eine saubere Entwicklunsumgebung haben, bevor Sie mit dem Bugfixing beginnen. Fixen Sie den Bug also nicht in einem lokalen Checkout, der Modifikationen enthält, die noch nicht deployed wurden.

Wenn Sie Hufabdrücke sehen, sollten Sie an Pferde denken, nicht an Zebras.

Wenn ein Fehler auftritt, nachdem Sie den Code geändert haben, dann ist es wahrscheinlich, dass Ihre Änderung den Fehler verursacht hat. Suchen Sie also dort. Entwickler sind gerne der Ansicht, dass die letzte Änderung so marginal war, dass sie keinen Fehler verursacht haben kann. „Sicher muss es ein Problem im Kernel sein, dass nur Donnerstags bei Regen auftritt und deshalb nicht entdeckt wurde.” Sehr wahrscheinlich ist das nicht das Problem, sondern die marginale Änderung war der Auslöser.

(Die einzige Ausnahme von dieser Regel ist, wenn Sie mit Destrukturen in PHP arbeiten, hier habe ich schon Phänomene erlebt, die nur von Scully und Mulder gelöst werden können. Beim Einsatz von Destruktoren in PHP gilt also – Trust No One.)

Nicht annehmen, sondern beweisen.

Obwohl ein Bug einem Entwickler beweist, dass er nicht unfehlbar ist, verhält man sich oft weiterhin so, als wäre man unfehlbar. Ein Entwickler nimmt dann bei der Fehlersuche einfach an, dass eine bestimmte Methode auf jeden Fall fehlerfrei funktioniert und überspringt diese beim Debuggen. Tun Sie das nicht. Prüfen Sie jede kleine Eventualität, jede noch so einfache Methode und beweisen Sie, das diese mit den Eingaben, die produktiv zu einem Fehler führen, korrekt arbeitet. Auch dieses Thema hatte ich bereits in „Don’t assume!” tiefergehend diskutiert.

Wenn Sie diese einfachen Regeln befolgen, dann haben Sie beim nächsten Bug deutlich höhere Chancen, diesen schnell, nachhaltig und ohne Folgefehler zu beseitigen.

Frisch im RSS-Reader

0

Seit ich mich entschlossen habe, selbst aktiv zu bloggen, habe ich auch wieder angefangen, regelmäßig andere Blogs zu lesen. Neu in meinem RSS-Reader sind jetzt:

Frank Westphal

Mit seinem Buch „Testgetriebene Entwicklung mit JUnit und FIT” verfolge ich in unregelmäßigen Abständen, was Frank Westphal veröffentlicht. Auf seiner Website veröffentlich er interessante Artikel zum Extreme Programming, Agiler Entwicklung und Qualitätssicherung. Seinen Podcast „Tonabnehmer” habe ich mir bislang noch nicht angehört, wären aber sicher ein guter Grund, Podcasts endlich mal auszuprobieren.

Neal Ford

Neal Ford ist Meme Wrangler bei Thoughtworks. Auf ihn bin ich bei einer Keynote auf der Dynamic Languages World aufmerksam geworden. Am meisten beeindruckt hat mich damals (und auch heute noch) sein Satz

Simplify essential complexity; diminish accidental complexity.

Diesem Satz hatten Holger Rüprich und ich auch eine unserer neun Regeln in unserem Workshop „Die Kunst des Software Design” auf der PHP World 2009 gewidmet.

Ludwig Ostrowski

Auf das Blog von Ludwig Ostrowski bin ich nur per Zufall (aka Twitter) gestolpert. In meinen Reader hat er es aus zwei Gründen geschafft:

  1. Seine neusten Einträge befassen sich mit Dependency Injection (und sogar PHP und Google Guice, meine Lieblingsthemen bei DI), Continuous Integration und Sonar. Alles Themen, die mich auch schon seit einiger Zeit fesseln.
  2. In seinem Blog zitiert er Martin Fowler mit einem meiner Lieblingszitate.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Ich werde das Blog auf jeden Fall mal im Auge behalten.

David Seah

Zum Abschluss noch ein Blog, das nichts mit Software-Entwicklung zu tun hat. David Seah schreibt über Design und Produktivität und kombiniert beides, in dem er wunderschöne Vordrucke für Tasklisten oder auch Ressourcenplanung zum kostenlosen Download anbietet. Zusammengefasst werden diese unter dem Namen „The Prinable CEO”, den David Seah wie folgt erklärt:

The Printable CEO name comes from the idea that a good CEO should focus primarily on those things that move the company forward; since I can’t afford to hire my own CEO, being able to print one out seemed like the next best thing!

Die Feeds

Sonar für PHP

0

In einem Blog Posting von SQLI durfte ich heute voller Freude lesen, dass bei SQLI daran gearbeitet wird, Sonar auch für PHP-Projekte nutzbar zu machen.

Sonar is an open platform to manage code quality. As such, it covers in its core version the 7 axes of code quality:

  • Architecture & Design
  • Duplications
  • Unit Tests
  • Complexity
  • Potential Bugs
  • Coding Rules
  • Comments

Im Java-Bereich setzen wir bei 1&1 Sonar bereits seit einiger Zeit erfolgreich ein. Nach jedem Commit erzeugt Hudson im Sinne der kontinuierlichen Integration einen kompletten Integrationsbuild, führt Tests aus und analysiert mit Hilfe von Checkstyle den gesamten Sourcecode. Die Ergebnisse davon werden in Sonar visualisiert und geben einen schnellen Überblick, wie es um die Qualität der Applikation bestellt ist. Dabei sind nicht die absoluten Kennzahlen das Maß aller Dinge, sondern mehr die Entwicklung, die die Projekte machen. Eine Testabdeckung von 5% ist grandios, wenn sie gestern noch bei 0% war.

Neben dem Nutzen für uns Entwickler bietet Sonar auch noch einen Nutzen für mein alter ego als IT Manager: Sonar berechnet uns mit Hilfe eines Plugins den technischen Kredit in Euro, den wir aufnehmen, wenn wir bei einer Entwicklung den Fokus auf den Liefertermin statt der Qualität setzen. Diese Zahl gibt Auskunft darüber, wie viel es unser Unternehmen kosten wird, die Applikation an unsere Qualitätsstandards anzupassen. Damit kann für Folgeprojekte argumentiert werden, da die Qualitätsprobleme für das Management sichtbar gemacht werden.

Eine Integration von PHP-Projekten in Sonar war schon lange mein Wunsch, da wir neben unseren Java-Applikationen auch einige business-kritische Applikationen mit PHP betreiben, die bislang noch nicht entsprechend analysiert werden.

Die Entwickler bei SQLI haben es jetzt geschafft, Daten aus SQLI_CodeSniffer (einem Wrapper für PHP_CodeSniffer), PHPUnit (mit XDebug code coverage), PHP_Depend und dem PHPUnit pmd Report in Sonar zu importieren. Im Blog Eintrag gibt es bislang leider erst ein paar Screenshots, produktiv kann das System noch nicht eingesetzt werden.

Ich werde die Entwicklung bei SQLI auf jeden Fall weiter beobachten und bin damit sicher nicht alleine.

nach oben