„If it hurts, do it more often“ ist das Credo, das die DevOps Bewegung populär gemacht hat. Aber das Prinzip ist alter Käse. Schon das XP Framework hatte in den 1990ern mit „Continuous Integration“ eine Praktik im petto, die auf dieser Einsicht fußt.
Paradoxerweise gewinnen Feature Branching und „Git Flow“ heute an Popularität und die unterliegende Einsicht scheint immer mehr in Vergessenheit zu geraten. Nur manchmal dämmert so manch einem die Erkenntnis, warum das Merging von langlaufenden Feature Branches immer so aufwendig ist und jedes Refactoring bei den Kollegen auf wenig Gegenliebe stößt.
Nach einer kurzen Rückbesinnung auf die ursprüngliche CI Praktik möchte ich euch zeigen, wie weit man mit dieser Praktik eigentlich gehen kann. Und welche Vorteile eine konsequente kontinuierliche Integration hat. Dabei meine ich nicht Continous Delivery. Wir werden uns mit den Techniken beschäftigen, die eine kontinuerliche Integration von Großen Refactorings möglich machen. Und wir werden sehen, dass man auch mit Depenendcies wie Libraries, Frameworks oder sogar Services kontinuierlich integrieren kann. Und das, ohne dass der Build durch „Upstream Changes“ kaputt gemacht wird. Aber auch das lästige Problem, dass ein kaputter Stand im Repo gelandet ist, wird uns beschäftigen.
Ihr werdet sehen, dass Continuous Integration mehr als nur das Aufsetzen eines Build Servers bedeutet. CI ist vielmehr eine Art zu arbeiten, die sehr viele Vorteile mit sich bringt.
Johannes Seitz studierte Informatik an der Goethe Universität Frankfurt und der ETH Zürich. Seit März 2015 arbeitet er als IT Architekt bei MaibornWolff im Bereich IT Sanierung. Zu seinen Interessen gehören Methoden der agilen Softwareentwicklung, DevOps und Softwarearchitektur. In seiner Freizeit schreibt und redet er gerne über sauberen Code und testgetriebene Entwicklung.