Code a little, Test a little, Deploy a little – Continuous Delivery im Großen

Print Friendly, PDF & Email

Software-Entwicklung ohne Branches und jede Code-Änderung sofort produktiv setzen. Das klingt abwegig? Die Großen machen es uns vor!

Boris Bokowski von Google hielt einen der beeindruckendsten Vorträge auf der diesjährigen OOP. Er berichtete darüber, wie bei Google Software entwickelt wird:

  • Bei Google arbeiten über 15.000 Softwareentwickler, verteilt auf über 50 Standort, die mehr als 100 Millionen Zeilen Code geschrieben haben.
  • Der vollständige Source-Code aller Google-Produkte liegt (mit ganz wenigen Ausnahmen) in einem einzigen Repository. Jeder Entwickler hat Zugriff auf den vollständigen Code und kann alles ändern.
  • Es gibt (wieder bis auf wenige Ausnahmen) keine Branches! Jeder Änderung wird auf trunk eingespielt.
  • Entsprechend gibt es keine versionierten internen Bibliotheken. Jedes Produkt nutzt immer den neuesten Stand jeder Bibliothek.
  • Jedes Team kann jederzeit eine Produktivsetzung starten, und zwar immer vom neueste Stand auf trunk.

Dieses Vorgehen zieht viele Konsequenzen nach sich. Die wichtigste ist: Jede Änderung am Sourcecode muss produktionsreif sein!

Das muss man erst einmal sacken lassen und verarbeiten. Jede Änderung, die ich jetzt einchecke, kann als Teil irgendeines anderen Produkts in der nächsten Stunde produktiv gesetzt werden.

Natürlich funktioniert dieses Vorgehen nur dann, wenn der Code durch viele Tests abgedeckt ist und eine Infrastruktur existiert, die diese Tests schnell laufen lässt. Google hat hierfür ein eigenes Build-System entwickelt, das nach jedem Check-in (>20/Minute) den Code baut und testet. Durch massive Parallelisierung und effiziente Caches erhält ein Entwickler die Testergebnisse meistens in unter fünf Minuten.

Entwickeln ohne Branches – geht das?

Mir fallen gleich mehrere Nachteile ein, die gegen ein gemeinsames Entwickeln in einem einzigen Repository ohne Entwicklungszweige sprechen:

  • Auf einem Feature-Branch können z.B. mehrere Entwickler gemeinsam neue Funktionalität entwickeln, ohne andere Entwickler auf trunk durch ihre Umbauten zu stören.
  • Ein länger lebender Release-Branch stellt sicher, dass man ganz gezielt kleine Änderungen produktiv setzen kann.
  • Die Erwartung, dass jeder Entwickler jederzeit produktionsreifen Code schreibt, erscheint unrealistisch.

Mit Sicherheit lassen sich noch mehr Argumente gegen das Vorgehensmodell von Google finden. Je genauer ich aber darüber nachdenke, desto mehr wird mir klar, dass viele dieser Argumente vorgeschoben sind: Ich müsste dazu nämlich meine eigene Arbeitsweise ändern.

Wenn ich nämlich halbfertige Entwicklungen nicht mehr für alle sichtbar machen kann, muss ich mich enorm disziplinieren. „Fast fertig!“ zählt nicht mehr. „Die Tests kommen noch!“ zählt auch nicht mehr. „Das hatte ich nicht bedacht!“ zählt noch weniger.

Entwickeln ohne Branches – will ich das?

Googles Ansatz, jede Änderung am Code sofort global wirksam werden zu lassen, bringt natürlich auch eine Reihe von Vorteilen:

  • Jedes Produkt profitiert sofort von jeder Innovation aller eingesetzten Bibliotheken.
  • Es entsteht kein Aufwand, Änderungen von Branches in den Haupt-Entwicklungszweig zurück zu mergen.
  • Abhängigkeiten auf veraltete Versionen gibt es nicht, dementsprechend müssen alte Versionen nicht gepflegt werden.
  • Groß angesetzte Migrationen oder Updates sind nicht notwendig, nur solche für jede einzelne Änderung.
  • Der Aufwand für Tests pro Release reduziert sich, da jedes einzelne Release klein ist und somit die Anzahl neuer Fehler gering sein muss. Die Ursachen für neue Fehler lassen somit erheblich besser eingrenzen.

Google hat sich also dazu entschlossen, die Kosten für Softwareänderungen an abhängigen Bibliotheken sofort zu zahlen, anstatt den Aufwand für die jeweils notwendige Migration nach hinten zu schieben.

Ich bezweifle, dass sich dieses Vorgehen auf beliebige Projekte übertragen lässt. Schließlich ist Google sehr wählerisch, welche Softwareentwickler eingestellt werden. Denn konsequent nur auf trunk zu entwickeln und von dort jederzeit neue Versionen produktiv zu setzen, erfordert vor allem eines: extrem eigenverantwortliche Entwickler!

Aber reizen würde es mich schon…

ps: Google ist mit diesem Ansatz nicht alleine. Flickr deployt zehn Mal am Tag neuen Code, Amazon gar im Schnitt alle 10 Sekunden. Und bei Facebook arbeiten 700 Entwickler an einer gemeinsamen Code-Basis.

Schreibe einen Kommentar

Fügen Sie die notwendige Nummer ins freie Feld ein *