Entscheidungen – schneller

Gestern ist via Twitter bei mir der offene Brief von Jeff Bezos an die Aktionäre von Amazon hereingeflattert. Er passt sehr gut in ein paar Beobachtungen die ich ebenfalls gemacht habe. Eine Dieser ist, dass es grösseren Unternehmen sehr schwer fällt schneller die richtigen Entscheidungen zu fällen. In einer Welt die sich immer schneller bewegt, wird dies aber immer mehr zu einem Erfolgsfaktor. Jeff nennt dies “High-Velocity Decision Making” und erläutert dazu vier Gedanken:

  • “…never use a one-size-fits-all decision-making process…”
  • “…most decisions should probably be made with somewhere around 70% of the information you wish you had…”
  • “…use the phrase ‘disagree and commit’…” ( das werden wir wohl in nächster Zeit sehr oft höhen  )
  • “…recognize true misalignment issues early and escalate them immediately…”

In der agilen Welt reden wir oft von Feedback-Cycle, hier geht es also um die Verkürzung des Decision-Making-Cycle als Teil des Feedback-Cycle, denn auch Jeff ist der Meinung, dass “customer focus” eine Firma vital hält. Continue reading “Entscheidungen – schneller”

Hypothesis-Driven Development

tl;dr

Ein gutes Werkzeug um Personen und Organisationen in der Softwareentwicklung (Teams, Management, etc) effektiver zu machen, ist sich auf die Dinge zu konzentrieren, die am meisten Wert für den Kunden haben. Um schnell Feedback zu bekommen etabliert man Continuous Delivery und damit man besser mit Unsicherheit umgehen kann hilft Hypothesis-Driven Development.

Man formuliert die Hypothesen nach folgendem Muster (Siehe auch: Quellen unten):

Wir glauben das <wenn wir diese Funktion bauen> 
für
<diese Personen>
liefert es  
<dieses Ergebnis>
Wir haben das Vertrauen fortzufahren, wenn wir (bis <Datum>) folgendes <messbare Signal sehen>.

Continue reading “Hypothesis-Driven Development”

Gradle wartet auf Service in Docker Container

Im Zusammenhang mit automatisierten Applikationstest war in einem späteren Schritt einer Deployment Pipeline eine Applikation in einer Testumgebung zu starten, um danach JUnit-Tests auszuführen. Die Applikation war eine Spring Boot Applikation innerhalb eines Docker Containers. Als Build Tool kam Gradle zum Einsatz. Wenn man nun mit Docker den Container startet, dann beendet das Docker CLI sofort nachdem es den Java-Prozess innerhalb des Containers gestartet hat. Will man nun sofort mit den Tests beginnen, dann ist die Spring Boot Applikation aber eventuell noch nicht vollständig gestartet und die Tests schlagen fehl. Continue reading “Gradle wartet auf Service in Docker Container”

Terraform und Exoscale

Derzeit bin ich mich am Umschauen, welche Cloudprovider in der Schweiz vorhanden sind und welchen Service sie in Bezug auf Automatisierung anbieten. Einer dieser Provider ist exoscale. In diesem Artikel möchte ich kurz beschreiben, wie ich Compute-Instanzen in Exoscale in Kombination mit Terraform erzeugen und wieder löschen kann. Eine solche Aufgabe nicht via einem graphischen User Interface zu machen – das von Exoscale ist sehr gut – sondern in Source Code zu formulieren, macht die Verwaltung der Infrastruktur in einem Source Code Repository möglich – Infrastructure As Code. Continue reading “Terraform und Exoscale”

Test-Säulen und Test-Treppe (Test-Pillars and Test-Stairs)

Wer sich mit Continuous Delivery und Testen auseinandersetzt kommt früher oder später an der Testpyramide vorbei. Die Mehrheit aller Tests sind Unit Test’s, darauf aufbauend wird auf Stufe Komponenten oder Services getestet und ganz oben auf der Pyramide wird die Gesamtheit des Systems getestet. Nach oben wird die Anzahl der Tests kleiner.

In diesem Artikel möchte ich einen Weg beschreiben, bei dem die Tests der oberen Stufen auch in den Tests der unteren Stufen ausgeführt werden und um weitere Tests auf jeder Stufe ergänzt werden. Das Ergebnis ist eher eine Stufenpyramide und das Vorgehen führt erstaunlich einfach an Domain Driven Design heran. Continue reading “Test-Säulen und Test-Treppe (Test-Pillars and Test-Stairs)”

Wie schnell bringt mein Unternehmen eine index.html Seite in die Produktion? (The Zero Dev Walk)

DevOps und Cross Functional Teams sind in aller Munde und wer es noch nicht kennt, dem sei das Buch “The Phoenix Project” von Gene Kim, Kevin Behr und George Spafford sehr empfohlen. Wie aber bekommt man aber nun ganz konkret heraus was zu tun ist? Was sind die konkreten Schritte, die gemacht werden müssen, damit eine DevOps Kultur entsteht? Continue reading “Wie schnell bringt mein Unternehmen eine index.html Seite in die Produktion? (The Zero Dev Walk)”

Docker 1.9.1 hängt mit Docker Toolbox auf Windows

diese Woche ist das Problem aufgetreten, dass auf den Entwicklerrechnern Docker Container einfach hängen geblieben sind und nicht mehr reagiert haben. Die Umgebung war ein Windows® 7 Prof mit Docker Toolbox. Der Fehler trat beim Starten einer docker-compose Konfiguration mit 4 Containern (zwei JBoss, zwei PostgreSQL) auf. Auch ein docker-compose stop oder rm -f war bei dem hängenden Container nicht mehr möglich. Windows zeigte an, dass ein Prozessor bei 100% ausgelastet ist.

Bei einigen Entwicklern hat es funktioniert, bei anderen nicht. Wie sich herausstellte, war bei Ersteren die Version 1.9.0 der Toolbox installiert, bei denen Zweiten eine Version 1.9.1.

Nach der Analyse des Problems, habe ich dann den Issue #18180 gefunden. Dort sind diverse Vorschläge dokumentiert, wie man das Problem lösen kann. In unserem Fall hat es geholfen den storage driver von docker engine auf overlay zu ändern. Wir haben dazu das Script (start.sh) hinter Docker Quickstart angepasst und bei der Erzeugung des Virtualbox Images mit dem Namen “default” noch folgenden Parameter angegeben:

... --engine-storage-driver overlay ...

Dies kann man aber auch direkt auf der Konsole machen, indem man die alte Maschine erst löscht und dann neu mit dem Treiber overlay anlegt:

docker-machine rm default
docker-machine create -d virtualbox --engine-storage-driver overlay default