Nachlese zur CITCON Europe 2014

Am 19. und 20. September fand die CITCON (ausgesprochen "kit-con") in Zagreb, Kroatien, statt. Die CITCON ist der kontinuierlichen Integration und dem Testen gewidmet. Sie bringt einige der interessantesten Persönlichkeiten der europäischen Testing- und Continuous Integration-Community zusammen. Diese Leute bestimmen auch die Themen der Konferenz.Sie können das tun, weil die CITCON eine Open Space Konferenz ist. Wenn Sie mit dem Konzept des Open Space nicht vertraut sind, schauen Sie bei Wikipedia nach. Am Freitagabend können die Teilnehmer ihre Vorschläge einbringen. Durch Punktabstimmungen und (ständiges) Umschichten des Zeitplans erstellen die Teilnehmer ihr Konferenzprogramm. In diesem Beitrag fassen wir einige Themen zusammen, die diskutiert wurden.

Polytesting

Peter Zsoldos(@zsepi) hat sich mit seinem neuesten Gedankenspiel beschäftigt: Polytesting. Wenn ich eine Reihe von Anforderungen habe, ist es dann möglich, diese Anforderungen auf verschiedenen Ebenen meiner Anwendung anzuwenden, z.B. auf Komponenten-, Integrations- und Benutzeroberflächenebene. Das klingt sehr verlockend, weil Sie ATDD auf verschiedenen Ebenen durchführen können.Dieser Ansatz ist besonders interessant, weil er das Potenzial hat, dass Sie sich ganz auf die erforderliche Funktionalität konzentrieren können. Damit dies funktioniert, brauchen Sie gute, konkrete Anforderungen.

Microservices

Microservices sind heutzutage ein heißes Thema. Das Versprechen von kleinen, isolierten Einheiten mit klaren Schnittstellen ist verlockend. Im Allgemeinen gibt es zwei Arten von Architekturen, die angewendet werden können. Die häufigste ist die, bei der es keine zentrale Einheit gibt und die Dienste direkt miteinander kommunizieren.Douglas Squirrel(@douglasquirrel) erläuterte eine alternative Architektur, bei der eine zentrale pub-sub "Datenbank" verwendet wird, in der jeder Dienst "Fakten" veröffentlichen kann. Douglas verwendet den Begriff Fakten bewusst, um einzelne Elemente zu beschreiben, die zu einem bestimmten Zeitpunkt als wahr angesehen werden ("Ereignisse" ist ein zu allgemeiner Begriff). Das zweite Modell kommt Mechanismen wie dem Event Sourcing (oder sogar ESBs, wenn Sie es auf die Spitze treiben) näher. Einer der Vorteile dieses Ansatzes besteht darin, dass es aufgrund der Speicherung von Fakten möglich ist, neue Funktionen auf der Grundlage vorhandener Fakten zu erstellen. Sie könnten diese Funktionalität zum Beispiel in einem Spiel verwenden, um Bestenlisten zu erstellen und zu einem späteren Zeitpunkt Bestenlisten pro Kontinent, Land oder was auch immer Ihnen geeignet erscheint, zu erstellen.

Unit-Tests

Arjan Molenaar hat dieses Jahr ein brandheißes Thema vorgestellt: "Unit-Tests sind eine Verschwendung". Angeregt durch die jüngsten Diskussionen von DHH, Martin Fowler und Kent Beck, versuchte Arjan, die Meinung der CITCON-Teilnehmer zu erfahren. Die meisten, die sich an der Diskussion beteiligten, müssen in der Beratung tätig gewesen sein, denn die wichtigste Schlussfolgerung lautete "Es kommt darauf an". Ob Unit-Tests den Aufwand wert sind, hängt hauptsächlich von den Zielen ab, die man mit dem Schreiben der Unit-Tests zu erreichen versucht. Manche Leute schreiben sie aus einer TDD-Perspektive. Sie verwenden Tests, um sich selbst durch die Entwicklungszyklen zu führen und sicherzustellen, dass sie keine kleinen Fehler gemacht haben. Wenn Ihnen das hilft, dann machen Sie bitte weiter so! Wenn es nicht wirklich hilft, nun ja ... Andere schreiben Unit-Tests aus einer Regressionsperspektive heraus oder pflegen sie zumindest für Regressionstests. Dieser Teil hat die meisten Diskussionen ausgelöst. Wie nützlich sind Unit-Tests für Regressionstests? Fangen Sie wirklich eine Regression ab, wenn Sie eine einzelne Unit isolieren? Das wachsende Interesse an Microservices wirft auch ein neues Licht auf diese Diskussion. In der Zukunft, wenn Microservices weit verbreitet sind, werden wir mit viel kleineren Codebases arbeiten. Sie könnten so klein und übersichtlich sein, dass Unit-Tests nicht mehr erforderlich sind, um uns durch den Entwicklungsprozess zu führen.

CI-Skalierung

Ein weiteres Trendthema war die Skalierung von CI-Systemen. Es war gut zu sehen, dass die Ideen, die wir bei Xebia haben, mit den Ideen übereinstimmen, die wir auf der CITCON gehört haben. Erstens: Die Lösung für alles (und den Weltfrieden, wie es scheint) sind Microservices. Leider müssen einige von uns im Moment noch mit monolithischen Codebasen arbeiten. Zum Glück gibt es immer noch Optionen für Ihr wachsendes CI-System, auch wenn es im Moment noch ein großer Klumpen Code ist. Die gestufte Pipeline: Sie testen die Dinge, die am wahrscheinlichsten kaputtgehen, zuerst. Im Grunde genommen teilen Sie Ihre Testsuite in mehrere Testsuiten auf und lassen sie in verschiedenen Phasen der Pipeline laufen. Aber wie bestimmen Sie, was am wahrscheinlichsten kaputt geht und was Sie wo testen? Die Tests, die am wahrscheinlichsten fehlerhaft sind, stehen in engem Zusammenhang mit den Codeänderungen. Bestimmen Sie außerdem die Bereiche mit hohem Risiko für Ihre Anwendung. Diese Bereiche können anhand von Trends (bei fehlgeschlagenen Tests) oder einfach durch menschliche Analyse ermittelt werden. Die Entscheidung, wo die verschiedenen Testsuiten ausgeführt werden sollen, ist hauptsächlich eine Frage der Geschwindigkeit und des Vertrauens. Sie wollen schnelles Feedback, also wollen Sie nicht alle Ihre Tests an das Ende der Pipeline schieben. Aber Sie wollen auch nicht ewig warten, bis Sie wissen, dass Sie mit dem nächsten Schritt weitermachen können.

Bierbrauen zur Prozessveredelung

Wer interessiert sich nicht für das Bierbrauen? Tom Denley(@scarytom) schlug eine Sitzung über Heimbrauen und die Analogie vor. Da Arjan selbst Heimbrauer ist, schien dies eine naheliegende Sitzung für ihn zu sein. Zusätzlich zu Toms Erklärungen zum Brauprozess haben wir darüber gesprochen, wie wir zum Brauen gekommen sind. In beiden Fällen wurde der erste Sud mit einer Dose gehopften Malzsirups hergestellt, Hefe hinzugefügt und daraus ein Bier gebraut. Für Ihr zweites Bier ersetzen Sie die Dose Sirup durch Malzextraktpulver und dunkles Malz (für den Geschmack). Zu einem späteren Zeitpunkt können Sie das Malzextrakt durch geschrotetes Malz ersetzen.Im Grunde beginnen wir mit dem Ziel vor Augen. Wenn Sie mit Continuous Delivery beginnen, gilt es als gute Praxis, dasselbe zu tun: Bringen Sie Ihre Anwendung so schnell wie möglich in Produktion und optimieren Sie Ihren Prozess von der bereitgestellten Anwendung zurück zum Quellcode.Es war wieder einmal eine gute Konferenz mit einigen netten Mitbringseln. Nächstes Jahr wird die Folge wahrscheinlich in Finnland stattfinden. Das Jahr danach... Die Niederlande?