Continuous Delivery mit Komponenten: "Küssen kann man nicht alleine"

JAXenter: "Küssen kann man nicht alleine" - mit dieser schönen Binsenweiheit startest du in die JAX. Ich nehme an, es wird trotz des menschlichen Titels um Softwareentwicklung gehen?

Hans Dockter: Die Annahme ist richtig, ich werde nicht anfangen zu singen ;).

Ich denke, wir stehen als Software-Community, was die Best Practices von Continuous Delivery anbelangt, noch ziemlich am Anfang. Wir haben viel Consulting in den letzten Jahren für sehr große Enterprise Builds gemacht. Über einen Teil dieser Erfahrungen möchte ich in diesem Talk sprechen. Es geht hier vor allem um die Skalierung von Continuous Delivery.

JAXenter: Zu den Best Practices von Continuous Delivery gehört es, dass Integrationen von Komponenten möglichst früh durchgeführt werden. Wie kann man das erreichen, ohne ein kontinuierliches Bauen der Gesamtanwendung zu behindern?

Hans Dockter: In Abhängigkeit von der Größe und Komplexität des Projektes, aber auch von der Qualität der involvierten Teams und der Code-Basis, funktioniert es irgendwann nicht mehr, seine Komponente lokal zu testen und dann seinen Code einfach zum Produktiv-Code zu committen. Die Wahrscheinlichkeit, dass die Gesamtapplikation dann nicht mehr funktioniert, wird zu hoch. Man hat zwar frühe Rückmeldung über Probleme, was das Ziel von Continuous Integration ist, aber man schafft es zu selten, neue Features den anderen Team, z. B. dem Test-Team, zur Verfügung zu stellen. Das verzögert die Auslieferung von Software und deren Qualität erheblich. Um diesen Fluss von neuen Features sicherstellen, braucht man zusätzliche Mechanismen, die den Produktiv-Code vor neuen Commits schützen. Mehr darüber in meinem Talk.

JAXenter: Du stellst auch die Neuerungen im Build-Werkzeug Gradle vor. Was hat sich in der letzten Zeit bei Gradle getan?

Hans Dockter: Wir haben in der letzten Zeit vor allem das Dependeny Management verbessert. Wir unterstützen weiterhin ivy.xml Dependency-Deskriptoren, nur verwenden wir Ivy nicht mehr intern als Library, sondern haben ein eigenes Dependeny Management implementiert mit vielen mächtigen Features und noch besserer Maven-Kompatibilität. Wir haben viel an der IDE-Integration mit Eclipse verbessert und sehr coole Änderung für das Java, Groovy und Scala Compilieren eingeführt. Außerdem haben wir viele kleine Dinge verbessert, auch das Error-Reporting. In meinem Gradle Talk werde ich einen umfassenden Überblick darüber geben. Und bevor ich es vergesse, in etwa zwei Wochen wird nach vier Jahren Entwicklungszeit Gradle 1.0 released.

JAXenter: Der nächste Schritt ist also Gradle 1.0. Was steht danach an?

Hans Dockter: Es gibt drei große Bereiche, in denen wir schnell Fortschritte machen wollen. Das sind parallele und verteilte Builds, zusätzliche Features für Gradle Multi-Project Builds, eine bessere Infrastruktur für das Gradle-Plug-in-Ökosystem sowie die Möglichkeit, beliebige Maven-Projekte und Maven-Plug-ins mit Gradle zu bauen.

JAXenter: Vielen Dank für Dein Update und viel Spaß auf der JAX!