Kanban im Überblick: Wie funktioniert diese agile Methode?

Der Kanban-Prozess ist ein Prozess der agilen Softwareentwicklung. Wie auch SCRUM hat Kanban Vor- und Nachteile.

Was ist Kanban?

Kanban ist zunächst ein Modell zur Produktionssteuerung gewesen. Ähnlich zu diesem Modell geht es auch in der Softwareentwicklung darum, parallele Prozesse abzubauen, um die bereits vorgefertigten Teile zum Abschluss zu bringen. Dies führt zu kürzeren Durchlaufzeiten einzelner Produkte (Software-Iterationsschritte) und zu schnelleren Releasezyklen.

Das Kanban-Board

Das Kanban-Board ist ein zentrales Element im Bereich Kanban. Es wird im Grunde durch eine einfache Tabelle abgebildet. Die einfachste Version stellt sich als Tabelle mit drei Spalten dar:

  1. Todo
  2. In Progress
  3. Done

Während Spalte zwei auf eine bestimmte Anzahl an Aufgaben begrenzt wird, können in den Spalten eins und drei beliebig viele Aufgaben (zum Beispiel dargestellt durch Klebezettel) abgelegt werden. Dabei muss bedacht werden, dass die Aufgaben in Spalte eins nach Abarbeitungsreihenfolge sortiert sein müssen. Sobald eine Aufgabe aus der Todo-Liste bearbeitet wird, wird sie in die „In Progress“-Spalte verschoben. Ist sie fertig, wird sie in die Spalte „Done“ verschoben – alternativ kann sie auch wieder nach „Todo“ zurückwandern.

Durch die anzuwendende Regel, dass in Spalte zwei nur eine begrenzte Anzahl an Aufgaben stehen darf, wird das Ziel der schnelleren Abarbeitung von Aufgaben gewährleistet. Geringere Fokuswechsel bedeutet weniger Verlust durch selbigen Overhead. Die Aufgaben werden in kürzeren Zeiten abgearbeitet und können somit auch schneller Geld einbringen.Natürlich kann dieses Board beliebig erweitert werden – es können Spalten wie „Test in Progress“, „Review in Progress“ oder ähnliches hinzukommen. Wichtig ist nur, dass jede Spalte zwischen der ersten und letzten Spalte (zwischen dem „Backlog“ und der „Erledigt“-Spalte) in der Anzahl der simultan darin abgelegten Tasks begrenzt sind.

Kanban Nachteile

Kein Vorgehensmodell ist perfekt. Dadurch lässt sich logisch schließen, dass jedes Entwicklungsmodell auch Nachteile hat. Einer der Nachteile ist das Starke Bedürfnis des Prozesses nach Disziplin aller Beteiligten. Sobald auch nur eine Person aus der Reihe fällt und sich nicht an eine der (wenigen) Regeln hält, gerät der Prozess schnell in’s wanken. Ebenso bietet das Vorgehen insofern keine „Eigenstabilität“, als dass es keine festen Zyklen gibt, in denen gearbeitet wird. Daraus folgt natürlich, dass sich jederzeit Priorisierungen oder die Reihenfolge der Abarbeitung von Aufgaben ändern können.

Kanban Vorteile

Vorteile sind unter anderem, dass die Reihenfolge von Aufgaben ständig geändert werden kann. Das führt zu einer extrem hohen Flexibilität. Ebenso ist der gesamte Prozess sehr „lean“, das heißt sehr schlank. Es gibt tägliche Standup-Meetings und unregelmäßig stattfindenden „Operations Reviews“ (eine Art Retrospektive). Fügt man diese beiden Meetings noch mit dem Begriff der „Root cause analysis“ (dem Beheben der Wurzel eines Problemes), so landet man direkt beim Kaizen.

Zusammenfassung

Zusammengefasst kann man sagen, dass Kanban sehr von der Flexibilität lebt, welche es bietet. Es ist ein sehr schlankes Vorgehensmodell der Softwareentwicklung und bietet eingespielten Teams sehr viele Möglichkeiten, die Workload zu optimieren. Für Teams, welche sich neu im Sektor der agilen Softwareentwicklung befinden, empfehle ich allerdings SCRUM. Dieses setzt auf ein paar mehr Regeln, besitzt ein etwas starreres Grundgerüst und gibt dadurch einen etwas strengeren Rahmen – für Anfänger ist es damit deutlich geeigneter, um erste Erfahrungen zu sammeln.

PhpStorm 2016.3 Neuerungen

Seit dem 01.09.2016 läuft das Early Access Programm für PhpStorm 2016.3 – doch was sind wichtige PhpStorm 2016.3 Neuerungen? Auf ein paar wichtige Punkte möchte ich im Folgenden eingehen.

PhpStorm 2016.3 Neuerungen

Dass PhpStorm 2016.3 in einer neuen EAP-Version released wurde, habe ich bereits in einem früheren Blogbeitrag erwähnt.

Mehrere Projekte in einem Fenster öffnen

Eine der größten Neuerungen an PhpStorm 2016.3 ist die Möglichkeit, mehrere Projekte parallel in einem Fenster („Frame“) geöffnet zu haben. Hier setzt ihr einfach ein Häkchen beim öffnen des Projektes, damit PhpStorm weiß, dass es das Projekt zum aktuellen in der Übersicht „hinzufügen“ soll. Achtung: „Per-Project“-Einstellungen werden in diesem Modus ignoriert!

Docker-Support für Remote-Interpreter

Ab sofort ist PhpStorm nun auch endlich in der Lage, Remote-Interpreter aus einem Docker-Container zu verwenden.

Autocompletion für Methoden und Felder ohne „var“ und „function“-Keyword

Eine weitere PhpStorm 2016.3 Neuerung ist, dass ihr nun auch eine Autocompleten für das Überschreiben von Konstanten und Co.

Projektweite PHP7 Strict-Types

Es gibt nun eine „Missing Strict Types Declaration“-Inspektion. Diese aktiviert den Strict-Type-Modus in PhpStorm und ist zu finden unter Settings|Editor|Code Style|Inspections|PHP|Type Compatibility. Diese Einstellung erzeugt eine Warnung in den PhpStorm-Inspections, sofern die Datei kein declare(strict_types=1); als erste Zeile enthält. Es ist auch in Planung, eine Art „automatische Korrektur“ zu implementieren, welche diese Zeile automatisiert überall hinzufügt.

Verbesserter Support für PSR-0/PSR-4

Die letzte, wichtige Neuerung, die ich euch vorstellen möchte, sind verbesserte Unterstützungen für PSR0 und PSR4. Die Funktionen „Create new text“ und „Create new class“ wurden verbessert und beachten die Standards PSR-0 und PSR-4 – sie erlaubeneuch nun auch das generieren von neuen Verzeichnisses. Ebenso beachtet PhpStorm 2016.3 bei der automatischen Erstellung von Testklassen nun das (im PhpStorm) markierte „Test Source Root“ und generiert in diesem Ordner automatisch die Datei passend zum Test.

 

Natürlich bringt PhpStorm 2016.3 noch viele weitere Neuerungen mit sich. Diese könnt ihr auf dem Blogeintrag direkt bei Jetbrains einsehen. Zu finden ist der Blogeintrag hier.

Was ist Agile Softwareentwicklung – Ein Einblick

Der erste Teil der Artikelserie zum Thema „Agile Softwareentwicklung“ wird sich mit der Definition beschäftigen, was überhaupt Agile Softwareentwicklung ist. Im darauffolgenden Teil des Artikels soll unter anderem auf Vorteile und Nachteile dieses Entwicklungsmodelles eingegangen werden. Weiterhin sollen ebenso die ein oder anderen Stolpersteine der „Agilität“ herausgearbeitet werden.

Was ist Agile Softwareentwicklung?

Die Agilität in der Softwareentwicklung beschreibt im Groben das Bestreben, einen möglichst flexibel handhabbaren Softwareentwicklungsprozess zu haben. Durch das eliminieren von unnötigem Verwaltungsaufwand, soll der Prozess schlank gehalten werden und die Softwareentwicklung soll in den Vordergrund treten.

Unter diesem flexibel handhabbaren Entwicklungsprozessen versteht man die Tatsache, möglichst zeitnah den Fokus von einem Thema auf ein anderes Thema setzen zu können. Hierbei soll nicht mehr im Vorhinein eine Art „Fünf-Jahres-Plan“ erstellt werden. Vielmehr es soll möglich sein, nach der Umsetzung des ersten Features ein beliebiges, zum Zeitpunkt der Erstellung von Feature 1 noch nicht bekanntes Feature, einwerfen und in die Umsetzung geben zu können.

Die genannte Agilität wird gestützt durch das sogenannte „Agile Manifest“, welches im Februar 2001 veröffentlicht wurde. Selbiges umfasst vier Grundwerte der „Agilität“:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

Schaut man sich diese Werte an, so geht es vordergründig nicht darum, sich an Prozessen, Befehlsketten und ähnlichem aufzuhalten. Vielmehr ist dafür zu sorgen, möglichst schnell ein (den Kundenanforderungen genügendes) funktionierendes Produkt zu liefern.

Vorteile des agilen Entwicklungsprozesses

Die Softwareentwicklung in ihrer agilen Form mag für den einen oder anderen sicher als eine Modeerscheinung bekannt sein. Diese Modeerscheinung bringt jedoch handfeste Vorteile mit sich. Beginnen wir mit dem Punkte der Risikobewertung. Einer der Fokuspunkte agiler Entwicklung liegt darin, ein Produkt in kurzen Iterationen umzusetzen. Aus diesem Vorgehen folgt, dass schlecht ankommende Versionen einer Software weniger negative Auswirkungen generieren. Nimmt man das Vorgehen per Wasserfallmodell als Vorbild, so ist diese (meist längere) Planungs- als auch Umsetzungszeit verloren. Agilität schränkt diesen Zeitraum stark ein, indem es kurze Iterationen fordert. Ein Feature nach dem anderen. Funktioniert dieses eine Feature nicht, sind lediglich die Zeiten für diese Iteration vergeben. Bei herkömmlichen Entwicklungsmethoden, muss das geplante und entwickelte Feature beim Kunden ankommen, ansonsten geht viel Geld verloren.

Ebenso vorteilhaft ist, dass man sehr viel schneller auf Marktgegebenheiten reagieren kann. Märkte und Kundenverhalten ändern sich häufig und teilweise sehr schnell. Genau diese Reaktionsfähigkeit durch agile Softwareentwicklung ist Gold wert: durch die Gegebenheit wenige Wochen an einer Softwareversion zu arbeiten, müssen keine langen Planungs- und Umsetzungsphasen verworfen werden. Im Gegenteil: Diese Arbeiten können abgeschlossen werden. Es muss keine, bzw. im Notfall nur wenig Arbeit verworfen werden und es kann direkt mit der Reaktion auf das Marktumfeld begonnen werden.

Ein weiterer, wichtiger Punkt ist der direkte Draht zwischen IT-Abteilung und Management. Auch wenn es nicht so wirkt: durch den frühen Einstieg der IT in die Planungen eines Features lassen sich verschiedene Fehlplanungen vermeiden, welche zum Beispiel im Wasserfallmodell zu einem großen „Knall“ und einem deutlichen Mehraufwand an Investitionen geführt hätten.

Nachteile agiler Entwicklung

Es ist nicht nur so, dass die agile Entwicklung ausschließlich Vorteile mit sich bringt. Sie bringt auch einige Nachteile mit sich. Nach meiner Erfahrung der letzten 2,5 Jahre sind sich (vor allem zu Anfang eines solchen Prozesses) viele Projektmanager nicht im klaren darüber, dass das Wort „agil“ nicht gleichzusetzen ist mit dem Wort „spontan“. Ein Kanban- oder SCRUM-Prozess verleiten sehr schnell dazu, doch noch das eine oder andere Ticket tauschen oder „in den Prozess quetschen“ zu wollen. Dass das nicht gewollt ist, sollte jedem verständlich sein. Auch ein agiler Prozess lebt von einer bestimmten Kontinuität. Diese erreicht man unter Verwendung von SCRUM beispielsweise durch das Einhalten der „Sprints“. Diese beschreiben das definieren eines Ziels binnen der nächsten 14 Tage und auch, dass sich an diesem Ziel möglichst nichts änder sollte.

Ebenso wirkt es sich nachteilig aus, dass wenige Entwickler und auch wenige Führungsrollen vertraut mit agiler Entwicklung sind. Es gilt, vor allem zu Beginn, auf die strikte Einhaltung besitmmter Regeln zu achten. In vielen Fällen werden Vorgehen wie SCRUM zunächst zu einem Naserümpfen im Management führen. Auf den ersten Blick wirken viele Meetings dieses Entwicklungsprozesses nach „Überfluss“. Gerade Meetings wie das Estimation-Meeting helfen jedoch auch dem Management ein besseres Gefühl für den Wert einer Aufgabe („User-Story“) zu bekommen. Auf die einzelnen Phasen des Sprints sowie die dazugehörigen Meetings werde ich jedoch in einem weiteren Artikel eingehen.

Artikelserie: Agile Softwareentwicklung

Mittlerweile ist die agile Softwareentwicklung in aller Munde – viele setzen hier vor allem auf den SCRUM-Prozess. Aus diesem Grund möchte ich mit Hilfe einer Artikelserie auf verschiedene Themen eingehen. Unter anderem werde ich hierbei erläutern:

Struktur der Artikelserie Agile Softwareentwicklung

  • Was ist agile Softwareentwicklung
    • Birgt das Vorgehen der agilen Entwicklung Vorteile?
    • Welche Nachteile sind mit der agilen Softwareentwicklung verbunden?
  • Was ist SCRUM?
    • Wie ist SCRUM aufgebaut?
    • Welche Phasen gibt es im SCRUM-Zyklus?
    • Was ist ein Sprint?
  • Was ist Kanban?
    • Wie funktioniert Kanban?
    • Bietet es Vorteile oder Nachteile gegenüber SCRUM?

Wie schon erwähnt soll das Ganze in die Form einer Artikelserie gegossen sein. Ich werde dabei vor allem viele praktische Erfahrungen einfließen lassen, welche ich innerhalb meiner letzten zwei Jahre als SCRUM-Master sammeln konnte.

Das Thema Agilität wird somit der Fokuspunkt dieses Blogs für die nächsten Tage und Wochen werden. Ich hoffe, mit dieser Serie einen echten Mehrwert im Internet zu schaffen – sofern ihr den einen oder anderen Artikel also interessant findet, teilt mir das gerne mit. Kommentiert fleißig und teilt den Artikel mit Freunden, Bekannten und Kollegen.

Finanzrechner für die Rente – wann bin ich dran?

In der heutigen Zeit sorgen sich immer mehr Menschen um ihre finanzielle Sicherheit während der Rente. Das Renteneintrittsalter wird gefühlt von Jahr zu Jahr immer weiter nach oben gesetzt – mittlerweile diskutiert man, ob nicht 72 oder mehr Jahre ein gutes Rentenalter wären.

Wem das alles zu kompliziert ist, der sorgt sich schlichtweg selbst um seine Rente. Doch wieviel Geld muss ich eigentlich auf die Hohe Kante legen und ab wann kann ich damit in Rente gehen? Ich selbst habe mich genau das gleiche gefragt. Aus diesem Grund habe ich angefangen, wilde Excel-Tabellen zu erstellen mit einem Wust aus Formeln, um mir meinen jetzigen Verdienst zu errechnen sowie meine Ausgaben in den Überblick zu bekommen. Daraus konnte ich später errechnen, wie lange ich wohl noch arbeiten gehen muss, um irgendwann von meinem angehäuften Kapital leben zu können.

Jeder, der sich dafür interessiert, schaut am besten mal das von mir programmierte Browsertool „Finanzrechner“ an. Ihr findet es auf meiner privaten Webseite unter einer Subdomain: http://finanzrechner.gunter-thomas.de/

Wenn ihr Featurewünsche habt, kontaktiert mich sehr gern. Das Programm ist noch im Aufbau und dahingehend noch sehr featurearm – aber ich versuche natürlich weiterhin, immer wieder sinnvolle und neue Features hinzuzufügen. Im Hinterkopf habe ich da bereits einiges, wie zum Beispiel den Zinsezins-Effekt für vorhandenes Kapital oder auch eine Variante der Anpassung verschiedener Ausgabearten mittels Schieberegler und daraufhin sofortiger Neuberechnung des Renteneintrittsalters.

Nicht beachtet werden auch hier eventuelle Gehaltserhöhungen in Zukunft. Der Rechner geht nur vom aktuellen Einkommen, sowie den aktuellen Ausgaben aus.

Schaut es euch an, probiert es aus. Aktuell ist es eher rudimentär – aber ich wollte es euch nicht vorenthalten einmal ausrechnen zu können, wann ihr in den Ruhestand übergehen könnt. Und nutzt die Möglichkeit, öfter vorbeizuschauen – ich werde versuchen, immer und immer wieder das eine oder andere neue und interessante Feature für euch zu ergänzen!

Buchempfehlung: PHP Design Patterns

Heute möchte ich euch eine Buchempfehlung im Bereich Entwurfsmuster („Design Patterns“) aussprechen. Das Buch, um welches es geht, nennt sich „PHP Design Patterns“ und wurde von Stephan Schmidt geschrieben. Es ist in der 2. Auflage vorhanden.

Warum empfehle ich das Buch? In meinen Augen gehört es klar zum Standardwerk eines jeden Softwareentwicklers. Wie der Name vermuten lässt, stellt das Buch einen starken Bezug zur PHP-Welt her. Auch wenn die Beispiele allesamt PHP Code sind, so sind sie in ihrer Art und Weise dennoch in fast allen OOP-Sprachen anwendbar. Genau das macht das Buch für mich so wertvoll – und auch deshalb ist es in meinem Bücherregal gelandet. Auch die Rezensionen auf Amazon überzeugen meiner Meinung nach sehr – das Buch hat 4,6 von 5 Sternen bei 34 Bewertungen bekommen.

Für alle, die noch nicht besonders fit in objektorientierter Entwicklung mit PHP sind findet sich zu Beginn des Buches ein kleiner Crash-Kurs, welcher die neuen PHP 5.3, bzw. generell den Objektorientierten Ansatz von PHP erläutert.

„PHP Design Patterns“ umfasst eine umfangreiche Auswahl von Design Patterns. Design Pattern sind Entwurfsmuster, welche euch dabei helfen sollen euren Quellcode zu strukturieren und sauber zu halten. Sie geben Lösungen für bereits vorhandene Probleme vor und bieten einen Lösungsansatz.

Alle Beispiele sind in diesem Buch sehr schön erläutert. Es werden öfter Bezüge zur Praxis gesucht um die Pattern an einem Beispiel zu erklären, welches nicht nur theoretische Anwendung findet. Das erhöht die Verständlichkeit merklich. Leider ist das Buch mit seinem Bezug zu PHP 5.3 etwas in die Jahre gekommen. Das macht aber dahingehend nichts, als das Design Patterns weiterhin ihre Gültigkeit behalten. Einige Quellcodestellen des Buches ließen sich jedoch mittlerweile sicher eleganter lösen.

In meinen Augen ein extrem gelungenes Buch und oftmals ein Standardwerk bei Entwicklern in der Webprogrammierung. Ihr solltet euch dieses 512 Seiten starke Buch unbedingt einmal anschauen! Kaufen könnt ihr es hier auf Amazon.

Ein Tag als Softwareentwickler

Der Beruf des Softwareentwicklers. Er beginnt irgendwann zu unchristlichen Zeiten und endet auch zu solchen. Dabei macht man nichts anderes, als den ganzen Tag vor einem Bildschirm zu sitzen und auf eine Tastatur einzuhacken. 120 Anschläge die Sekunde – acht Stunden am Tag durchweg, sodass sich der schwarze Bildschirm mit immer mehr weißen Zeichen füllt. Am Ende drückt man dann einmal auf die ENTER-Taste und zack – wir sind drin, im System der NSA. Zumindest, wenn es nach vielen Filmen geht.

Doch wie läuft so ein Tag im Leben eines Softwareentwicklers wirklich ab? Ein Tag im Leben eines Softwareentwicklers könnte wie folgt ablaufen:

Das Entwicklerleben …

… beginnt in den meisten Fällen zunächst einmal mit dem erscheinen auf Arbeit. Sachen abgelegt, schon einmal den PC einschalten und danach ab in die Küche – erstmal einen Kaffee ziehen und eine Flasche Wasser greifen. Zurück mit der Ausrüstung am Arbeitsplatz am PC einloggen und – genau, ihr wusstet es – eMail-Client öffnen. Emails lesen. Die Hände über dem Kopf zusammenschlagen. Emails beantworten. Noch schnell ein kurzer Blick über das Ticketsystem werfen – gibt es zu meinen Zwischenständen von gestern etwas neues? Sind die fertig bearbeiteten Tickets abgenommen, oder muss ich nachbessern und Bugs fixen? Nun, ist auch egal – es ist schon wieder 09:30 und damit Zeit für unser daily Stand-Up. Beeilung, der SCRUM-Master steht schon in der Tür.

Das Daily StandUp

Das Daily- oder auch Standup-Meeting ist ein 10-15 minütiges Meeting. Dabei bildet die Entwicklerschaft einen Halbkreis – mit der offenen Seite zum Backlog, welches entweder in analoger Form auf einer Tafel oder in digitaler Form mit dem Beamer an die Wand projeziert wird. Es dient dem kurzen Austausch über den aktuellen Entwicklungsstand innerhalb des Teams. Ziel ist es, den Tag zu planen: welche Themen will ich heute angehen? Bei welchen brauche ich noch Zuarbeit? Was bekomme ich noch fertig heute, bei welchen Tickets brauche ich länger? Gibt es irgendetwas wichtiges, auf das ich meine Teammitglieder hinweisen möchte?

Nachdem wir diese ganzen Diskussionen hinter uns gebracht haben, geht es wieder zurück an den Arbeitsplatz.

Zurück am Platz – endlich programmieren!

Endlich zurück am Platz, blinkert schon wie wild der Jabber-Client. Och Mensch, da braucht wieder jemand aus dem anderen Bereich Zuarbeit. Nun gut – nach fünf maligem fragen aufgrund von schwammiger Erklärun und mehrmaliger spontaner Abwesenheit des gegenüber nehme ich eben kurz den Telefonhörer in die Hand. Rufe ihn an. Die Sache ist in zwei Minuten geklärt. Endlich. Programmieren!

Also die IDE geöffnet, nochmal kurz mittels eines git pull die Arbeitskopie aktualisiert. Browser geöffnet, Refresh gedrückt. BAM. Error 500. Wer war’s? Natürlich keiner. Spitze. Also nun push-History nachschauen und einzeln prüfen, woher der Fehler kommt? Oder lieber gleich fixen? Ich entscheide mich für zweiteres. 20 Minuten später ist das Problem gelöst. Der Quellcode eingecheckt, alle anderen können wieder arbeiten. Es ist Mittagspause.

Zurück am Platz – endlich programmieren!

Nun beginnt der eigentlich spannende Teil des Tages: jetzt habe ich eine funktionierende Arbeitsumgebung. Alle Mails sind abgefrühstückt. Gegessen habe ich. Los geht’s!

Nach ungefähr 45 Minuten werde ich unterbrochen. Eine Projektmanagerin steht neben mir. Sie will den Stand des Features wissen. Ich sage ihr, dass ich heute wohl das gröbste schaffe und wenn nichts dazwischen kommt, werde ich das Feature morgen finalisieren und es an die Testabteilung geben. Das stellt sie soweit zufrieden. Sie verlässt das Büro. 10 Minuten später steht mein Scrum-Master neben mir und fragt nach, seit wann ich solche kurzfristigen Termine herausgebe. Verwirrt frage ich ihn, was er meint – die Projektmanagerin stand bei ihm am Tisch und wollte ein Release für morgen haben. Sie meinte, das Feature sei morgen fertig hätte ich gesagt. Nachdem ich ihm die Situation erklärt habe, wird er nun der Projektmanagerin den Wind aus den Segeln nehmen müssen. Ich programmiere weiter.

Mittlerweile bin ich tatsächlich zwei Stunden ungestört gewesen, als sich ein weiterer Kollege meldet. Er benötigt Hilfe. Wir setzen uns zusammen an seinen Platz und tauschen Wissen aus, begeben uns auf Fehlersuche. Die Zeit vergeht – wir finden den Fehler und können ihn eliminieren. Wir schreiben ein weiterführendes Ticket – unsere Hack-artige Lösung muss dringend durch etwas Hand- und Fußfestes ersetzt werden. Das Ticket wird wohl (so wie die 25 anderen der letzten 14 Tage) im Nirvana verschwinden.

Als ich wieder an meinem Arbeitsplatz sitze, pingt mich ein Kollege an – er macht für heute Feierabend, hat aber noch ein Ticket fertiggestellt. Ich solle mir seinen Quellcode anschauen und ein Code-Review anfertigen, damit die Tester morgen direkt mit den manuellen Tests starten können. Da das Code-Review Teil meiner Arbeit ist, verspreche ich ihm das Ganze heute noch durchzuziehen – er bedankt sich, wünscht einen schönen Feierabend. Ich wünsche das gleiche, beginne direkt mit dem Code-Review. Meine zwei kleinen Anmerkungen passe ich direkt selbst an, schiebe das Ticket auf coding finished und gebe es an die Testabteilung weiter. Per eMail benachrichtige ich meinen Kollegen noch darüber, dass ich zwei kleine Anpassungen durchgeführt habe – das Review sonst aber gut aussah. Aus der Bahn sendet er mir eine Antwort-eMail und bedankt sich.

Mittlerweile ist es Abend. Nach drei Stunden Programmierung und der sonstigen „Daily Routine“ verlasse ich das Büro. Geschafft habe ich wie immer gefühlt nichts, was in meiner Ticketliste stand. Zu tun hatte ich dennoch ordentlich. Morgen werde ich mir direkt meine großen Kopfhörer aufsetzen. Vielleicht bin ich dann ungestört und kann das Feature fertigstellen …

PHPStorm 2016.3 EAP und PHP 7.1.0 RC1

Eine kurze Nachricht zum Abend:

Seit heute gibt es die neue PHPStorm EAP 2016.3 – die Build-Nummer lautet 163.3512
Eine ausführliche Beschreibung aller neuen Features findet ihr auf der PHPStorm Seite. Dort findet ihr auch den Download sowie eine komplette Liste aller Änderungen aus dem YouTrack.

Außerdem wurde vor wenigen Stunden der PHP 7.1.0 RC1-Branch überarbeitet und in den Master überführt und ein Tag erstellt. Zu finden ist das Ganze auf dem GitHub-Account von PHP. Ebenso scheinen schon die ersten Änderungen für die RC2 eingearbeitet zu sein. Einen Tag davon gibt es jedoch noch nicht.

Da kann man nur happy Updating wünschen – bitte benutzt nichts davon produktiv!

Continuous Integration

Continuous Integration – das Wort kommt einem bereits seit einiger Zeit sehr oft zu Ohren. Doch was ist das eigentlich? Für was braucht man das? Und wieso finden das eigentlich so viele Leute toll?

Continuous Integration? Continuous Delivery und Deployment?

Generell ist Continuous Integration (viele kürzen es mit „CI“ ab) sehr nah am Thema Continuous Delivery und Continuous Deployment. Aus diesem Grund, möchte ich im folgenden Text kurz die drei Begriffe voneinander differenzieren:

  • Continuous Integration: beschreibt das kontinuierliche Zusammensetzen und testen der Quellcodebasis in einem automatisierten Prozess
  • Continuous Delivery: ist die Weiterentwicklung der Continuous Integration und beschreibt den ständig deploybaren Zustand einer Software, es liegt also ständig eine verteilbare Version der Software vor
  • Continuous Deployment: ist der letzte logische Schritt dieser Kette und besagt, dass die kontinuierlich integrierte Version der Software (welche nun auch zu jeder Zeit deploybar ist) mit jedem neuen (und funktionierendem Build) automatisiert verteilt wird

Warum das Ganze?

Da wir nun wissen, was Continuous Integration ist fragen wir uns sicher: warum betreibt man so einen Aufwand, ständig releasebare Software zu haben? Man baut doch erst ein Feature zu Ende, testet das und schiebt es dann zur Marktreife ab in’s Deployment.

Nun, hier muss man die Brücke zum Thema „Agile Softwareentwicklung“ schlagen. Da man bestrebt ist vollzogene Änderungen möglichst schnell und zeitnah an den Kunden ausspielen zu können, müssen Fehler möglichst Ressourcenschonend und schnell erkannt werden. Hierbei hilft natürlich eine CI-Pipeline, welche direkt zum Zeitpunkt des pushens von Quellcode die Applikation neu baut und mittels automatischen Tests bereits prüft.

Ebenso ist es natürlich im Sinne agiler Software (auch wenn wir ein wenig vom Thema Continuous Integration abschweifen, so ist es doch ein gutes Hilfsmittel der agilen Softwareentwicklung), das Produkt möglichst schnell am Kunden ausprobieren zu können. Hierfür muss gewährleistet sein, dass das Produkt ständig funktioniert und im optimalen Fall auch ständig ausgespielt werden kann. Ein Feature, welches nicht performt, muss entweder angepasst werden – damit es funktionieren kann – oder es sollte frühzeitig eingestampft werden wenn es kein Geld bringt.

Umso komplexer natürlich der Quellcode beim „verheiraten“ der Entwicklung ist, umso fehleranfälliger wird das Ganze. Ein frühzeitiges, ständiges integrieren und testen der entwickelten Teile des Softwaresystems bringen also einen großen Vorteil mit sich – da durch das ständige Zusammenführen stärker eingegrenzt werden kann, was die mögliche Fehlerquelle ist.

Welche Software bildet das alles ab?

Es gibt so einige Tools, welche zur Unterstützung eines CI-Prozesses verwendet werden können. Die zwei bekanntesten hierfür dürften Travis-CI und Jenkins sein.

Jenkins ging damals aus dem Hudson-Projekt hervor und ist seit jeher ein sehr flexibles und anpassbares Tool zum Umsetzen von CI-Pipelines. Ebenso bekannt ist Travis-CI. Dieses verfügt über eine direkte Anbindung an GitHub und liefert hier (durch das einchecken einer .travis-ci.yml-Datei) eine hohe Flexibilität durch direkt im Repository befindliche Taskbeschreibungen.

Die Ansätze hierbei sind sehr verschieden. Während man für Jenkins direkt die auszuführenden Tasks im Jenkins selbst konfiguriert, geht Travis-CI den umgekehrten Weg. Die Tasks werden hier direkt im Repositry beschrieben. Anmerkung: es gibt auch für Jenkins ein Plugin, welches den Travis-CI-Weg zur Verfügung stellt.

Vermutlich etwas weniger bekannt dürfte Gitlab-CI sein. Gitlab ist eine hochintegrierte Umgebung, welche ein Git Repository und ein Continuous Integration System ineinander vereint. In meinen Augen sind alle drei Tools gelungen – wenngleich Gitlab-CI und Travis-CI ein wenig die Nase vorn haben, da sie ohne weiteren Extra-Konfigurationsaufwand „Out of the Box“ mit ihren Quellcodemanagementsystemen verzahnt sind.

Links:

  • https://gitlab.com
  • https://jenkins.io
  • https://travis-ci.com