Developer Productivity Engineering

Slide 1

Slide 1 text

Developer Productivity Engineering Marc Philipp Principal Software Engineer, Gradle Inc.

Slide 2

Slide 2 text

Marc Philipp Principal Software Engineer bei Gradle Inc. JUnit team lead Twitter: @marcphilipp E-Mail: marc@gradle.com Wer bin ich?

Slide 3

Slide 3 text

Wer ist Gradle Inc.? ⬢ Ursprünglich gegründet als GmbH in Deutschland ⬢ Mittlerweile Startup mit Hauptsitz in San Francisco ⬢ Fully Remote

Slide 4

Slide 4 text

Was macht Gradle Inc.?

Slide 5

Slide 5 text

⬢ Gradle User ⬢ Maven User ⬢ Verantwortlich für Build/CI Pipeline/Entwicklerproduktivität ⬢ Manager eines Softwareteams Wer sind Sie bzw. seid ihr?

Slide 6

Slide 6 text

Agenda Warum Developer Productivity Engineering? Schnelle Feedbackzyklen Zuverlässige Builds

Slide 7

Slide 7 text

use at will Warum Developer Productivity Engineering?

Slide 8

Slide 8 text

Software-Entwicklung ist ein kreativer Prozess ⬢ Kreativität wie die eines Wissenschaftlers ⬢ Im Dialog mit der Toolchain ⬢ Qualität des Dialogs bedingt kreativen “Flow” ⬢ Ideal: sofort zuverlässige Antworten

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

Software-Entwicklung erfordert Zusammenarbeit ⬢ mit den Businessexperten/Kunden ⬢ Code = Interpretation einer Geschäftsidee ⬢ Zusammenarbeit erfordert Iterationen ⬢ Je kürzer die Iterationen desto effektiver die Zusammenarbeit

Slide 11

Slide 11 text

Qualität des kreativen Flows + Effektivität der Zusammenarbeit Produktivität des Teams

Slide 12

Slide 12 text

Software-Entwicklung ist komplex ⬢ Toolchain ist komplex mit komplexen Eingaben ⬢ Toolchain beeinﬂusst ○ Geschwindigkeit der Iterationen ○ Feedbackzyklen ○ Zuverlässigkeit des Feedbacks ⬢ Efﬁzienz der Toolchain ist der Schlüssel zu kreativem Flow und effektiver Zusammenarbeit

Slide 13

Slide 13 text

The Paradox of Success ⬢ Exponentiell wachsende Metriken in erfolgreichen Projekten ○ Lines of Code ○ Anzahl Entwickler ○ Anzahl Repositories ○ Anzahl Abhängigkeiten ○ Anzahl verwendeter Technologien ⬢ Ergebnis ○ Ohne Zutun degradiert die Efﬁzienz der Toolchain ○ Vergrößern des Teams hat fast keinen Einﬂuss mehr

Slide 14

Slide 14 text

Developer Productivity Engineering ⬢ Anstrengung der ganzen Organisation Entwicklerproduktivität zu steigern ⬢ Ein Expertenteam mit Fokus auf Efﬁzienz der Toolchain ○ Hoher Grad an Automatisierung ○ Schnelle Feedbackzyklen ○ Zuverlässiges Feedback ⬢ Prioritäten und Ziele basieren auf Daten der instrumentierten Toolchain

Slide 15

Slide 15 text

Teampotential ⬢ Große Lücke zwischen aktueller Teamproduktivität und vollem Potential ⬢ Lücke wächst über Lebenszeit des Projekts ⬢ Developer Productivity Engineering kann die Lücke kleiner machen

Slide 16

Slide 16 text

Glückliche Entwickler ⬢ Entwickler wollen eine Umgebung die es erlaubt ihr Potential zu entfalten ⬢ Entwickler verlassen Unternehmen die keine solche Umgebung liefern können

Slide 17

Slide 17 text

Innovation ⬢ Wettbewerbsnachteil durch geringe Entwicklerproduktivität ⬢ Umsetzungsprobleme von Geschäftsinnovationen in Software

Slide 18

Slide 18 text

Wie überzeuge ich meinen Chef? ⬢ Vorteile quantiﬁzieren ⬢ Effekt eines Developer Productivity Teams aufzeigen

Slide 19

Slide 19 text

Was ist Gradle Enterprise? Ein DevProd Engineering Tool, das Daten von Builds sammelt, Analysen ermöglicht und Builds sowie Tests beschleunigt. Instrumentiert Gradle und Maven Builds

Slide 20

Slide 20 text

use at will Schnelle Feedbackzyklen

Slide 21

Slide 21 text

Schnelle Builds verbessern kreativen Flow Team 1 Team 2 # Entwickler 11 6 Build-Dauer 4 m 1 m # lokale Builds 850 1010 ⬢ Schnelleres Feedback → öfter Feedback ⬢ Öfter Feedback → kleinere Änderungen

Slide 22

Slide 22 text

Sogar relativ schnelle Builds erzeugen Wartezeit ⬢ Entwickler warten auf schnelle Builds ⬢ Hohe Wartezeit sogar für sehr schnelle Builds ⬢ Unzuverlässige Toolchain erhöht Wartezeit Entwickler Lokale Builds/Woche Build-Dauer Optimierte Build-Dauer Ersparnis/Jahr 6 1010 1 m 36 s 44 Tage 100 12000 9 m 5 m 5200 Tage

Slide 23

Slide 23 text

Langsame Builds führen zu Kontextwechseln ⬢ Entwickler arbeiten an anderen Tasks für langsame Builds ⬢ Kontextwechsel zurück wenn ○ der Build fehlschlägt ○ Feedback notwendig für weitere Entwicklung ⬢ Kontextwechsel kostet ca. 10-20 Minuten ○ mal 2 ○ Unzuverlässige Toolchain erhöht die Kosten wesentlich

Slide 24

Slide 24 text

Fehlersuche bei langsamen Builds ⬢ Langsamer Build ⇒ mehr Änderungen pro Build ⬢ Mehr Änderungen pro Build ⇒ schwierige Fehlersuche ⬢ Speziell auch für CI-Builds

Slide 25

Slide 25 text

Kosten der Fehlerbehebung Die Zeit einen Fehler zu beheben wächst exponentiell mit der Zeit, die benötigt wird, ihn zu erkennen.

Slide 26

Slide 26 text

Teufelskreis Beispiel: Merge-Konflikte ⬢ Langsame Builds ⇒ mehr Änderungen / Build ⬢ Build fixen dauert länger ⬢ Erfolgreiche Builds noch länger ⬢ Mehr Merge-Konflikte

Slide 27

Slide 27 text

Ursachen und Effekte ⬢ Schnelle Builds ⇒ hohe Wartezeiten ⬢ Langsame Builds ⇒ hohe Wartezeiten + viele Kontextwechsel ⬢ Microservices ○ Schnelle Builds / Repo ○ Producer bricht unbemerkt Consumer ○ Integrationsprobleme oft spät erkannt

Slide 28

Slide 28 text

Lange Feedbackzyklen sind toxisch ⬢ Schlechter kreativer Flow ⬢ Wartezeiten auf Feedback ⬢ Bugﬁxes exponentiell teurer ⬢ Feedback kommt in späteren Stufen ⬢ Größere Changesets ⬢ Frustrierte Entwickler

Slide 29

Slide 29 text

Wie lassen sich Builds beschleunigen? ⬢ Schneller heißt weniger machen ⬢ Inkrementelle Builds ⬢ Build Cache

Slide 30

Slide 30 text

Build Cache ⬢ Eingeführt durch Gradle 2017 ⬢ Verfügbar für Maven und Gradle ⬢ Komplementär zum Dependency Cache ○ Dependency Cache: Binäre Abhängigkeiten (andere Repositories) ○ Build Cache: Ergebnisse von Build Aktionen (gleiches Repository)

Slide 31

Slide 31 text

Build Caching Wenn die Inputs eines Tasks/Goals sich nicht verändert haben, können die Outputs eines vorherigen Builds wiederverwendet werden.

Slide 32

Slide 32 text

Beispiel Java-Kompilierung ⬢ Inputs: ○ Sourcen ○ Compile-Classpath ○ Java-Version ○ Compilerargumente ○ … ⬢ Outputs: ○ Kompilierte Klassen

Slide 33

Slide 33 text

Für Maven erfordert jede Änderung einen kompletten Rebuild (ohne Build Cache). Bei Gradle ist dies der Fall, wenn eine “clean” Build gemacht wird oder zwischen Branches gewechselt wird.

Slide 34

Slide 34 text

Änderung an der Signatur einer public-Methode im Modul “export-api”

Slide 35

Slide 35 text

Änderung an der Signatur einer public-Methode im Modul “service”

Slide 36

Slide 36 text

Änderung eines Implementierungsdetails im Modul “service”

Slide 37

Slide 37 text

Änderung eines Implementierungsdetails im Modul “core”

Slide 38

Slide 38 text

Änderung an der Signatur einer public-Methode im Modul “core”

Slide 39

Slide 39 text

Remote Build Cache ⬢ Beschleunigt Builds für das gesamte Team ⬢ Wiederverwendung von Build Outputs zwischen CI Agents und Entwicklerrechnern

Slide 40

Slide 40 text

Build Cache für Gradle und Maven ⬢ Gradle ○ Lokaler Cache ist Teil des Build Tools ○ Remote Cache via Gradle Enterprise ⬢ Maven ○ Lokaler und Remote Cache benötigt Gradle Enterprise

Slide 41

Slide 41 text

Gradle: Noch schnellere inkrementelle Builds ⬢ Inkrementelle Groovy-Kompilierung (seit Gradle 5.6) ⬢ File System Watching (seit Gradle 6.5) ⬢ Conﬁguration Caching (seit Gradle 6.6)

Slide 42

Slide 42 text

Distributed Testing (Teil von Gradle Enterprise) ⬢ Idee: Beschleunigung der Ausführung von Tests durch parallele Ausführung auf Agents ⬢ Automatische Partitionierung des Testmenge anhand zuvor aufgezeichneter Ausführungszeiten ⬢ Automatische Übertragung aller benötigten Dateien auf die Agents sowie in der Rückrichtung von Dateien, die während der Ausführung geschrieben werden (z.B. JaCoCo). ⬢ Test Reporting funktioniert wie bei lokaler Ausführung ⬢ Verwendbar für lokale als auch CI Builds

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

use at will Ohne Daten keine schnellen Builds

Slide 45

Slide 45 text

⬢ Infrastrukturänderungen ○ Artefakt-Repositories ○ Caching ○ CI Agents ⬢ Neuer Annotationprozessor Builds werden leicht langsamer ⬢ Änderungen in der Build-Logik ○ Speicher ○ Build-Tool Versionen ⬢ Codeänderungen ⬢ Neue Niederlassungen

Slide 46

Slide 46 text

Was passiert mit Performance-Regressionen? ⬢ Unbemerkt ⬢ Bemerkt aber nicht kommuniziert ⬢ Kommuniziert aber nicht behoben ○ Ursache zu ﬁnden ist schwierig ○ Auswirkungen und Priorität unklar ○ Wer am lautesten schreit, gewinnt ⬢ Schwere Probleme werden eskaliert ○ leider erst nachdem sie viele Schmerzen und Kosten verursacht haben ⬢ Ergebnis: Buildzeiten sind viel höher als nötig und steigend

Slide 47

Slide 47 text

Ausweg: Daten für alle Builds ⬢ Mit Daten kann man ○ große Regressionen sofort erkennen ○ Ursachen leichter ﬁnden ○ Probleme beheben bevor sie zu großen Problemen werden ⬢ Daten erlauben leichtere Priorisierung ⬢ Ergebnis: weniger Probleme und Builds werden kontinuierlich schneller

Slide 48

Slide 48 text

Daten, woher? ⬢ Für alle Builds: Entwicklerbuilds und CI ⬢ Build Scans: Lösung in Gradle Enterprise ○ Demo: https://ge.junit.org/ ○ Kostenlose Nutzung auf https://scans.gradle.com

Slide 49

Slide 49 text

use at will Zuverlässige Builds

Slide 50

Slide 50 text

Unzuverlässige Builds und Tests machen wahnsinnig

Slide 51

Slide 51 text

Wir kennen es alle... ⬢ Alles läuft gut - nur noch ein paar Tests laufen lassen ⬢ Irgendwas, das nichts mit der Änderung zu tun hat, schlägt fehl ○ Kryptischer Fehler, nicht mein Gebiet ○ Wessen Gebiet ist das überhaupt? ○ Rest des Tages: Fehler ﬁnden statt an meinen Sachen arbeiten ○ Alternativ: Build nochmal laufen lassen

Slide 52

Slide 52 text

Verschiedene Fehlerarten ⬢ Veriﬁkationsfehler (gutartig) ○ Compilefehler ○ Checkstyle ○ Test-Fehlschlag ⬢ Kein Veriﬁkationsfehler (bösartig) ○ Flaky Test ○ Repository nicht verfügbar ○ OutOfMemory während Build

Slide 53

Slide 53 text

Was passiert mit unzuverlässigen Builds? ⬢ Bemerkt aber nicht kommuniziert ⬢ Kommuniziert aber nicht behoben ○ Ursache zu ﬁnden ist schwierig ○ Auswirkungen und Priorität unklar ○ Wer am lautesten schreit, gewinnt ⬢ Schwere Probleme werden eskaliert ○ leider erst nachdem sie viele Schmerzen und Kosten verursacht haben ⬢ Ergebnis: Unzuverlässige Builds

Slide 54

Slide 54 text

Ausweg: Daten für alle Builds ⬢ Mit Daten kann man ○ Häuﬁgste Probleme erkennen ○ Ursachen leichter ﬁnden ○ Probleme beheben bevor sie zu großen Problemen werden ⬢ Daten erlauben leichtere Priorisierung ⬢ Ergebnis: weniger Probleme und Builds werden kontinuierlich zuverlässiger

Slide 55

Slide 55 text

Daten, woher? ⬢ Für Entwicklerbuilds und CI ⬢ Build Scans: Lösung in Gradle Enterprise ⬢ Demo: Failure Dashboard

Slide 56

Slide 56 text

Umgang mit Flaky Tests ⬢ 1. Schritt: Erkennung ○ Test Retry Plugin für Gradle ○ Rerun-Konfiguration für Maven Surefire Plugin ⬢ 2. Schritt: Priorisierung nach Häufigkeit ○ Sammeln von Daten über Auftreten ⬢ 3. Schritt: Behebung ○ Testcode flaky? ○ Produktionscode flaky? ⬢ 4. Schritt: Erneute Betrachtung der Daten mit einer gewissen Verzögerung

Slide 57

Slide 57 text

Daten, woher? Test Dashboard: Lösung in Gradle Enterprise

Slide 58

Slide 58 text

Zusammenfassung ⬢ Ohne Zutun werden Builds langsamer und unzuverlässiger ⬢ Mit Daten von allen Builds kann man ○ häuﬁgste Probleme erkennen ○ Ursachen leichter ﬁnden ○ Probleme beheben bevor sie zu großen Problemen werden ⬢ Ergebnis: Developer Productivity Engineering macht Builds kontinuierlich schneller und zuverlässiger

Slide 59

Slide 59 text

Links ⬢ Kostenlose Trainings für Gradle und Gradle Enterprise: https://gradle.com/training/ ⬢ Kostenloses Developer Productivity Ebook: https://gradle.com/developer-productivity-engineering/ ⬢ Build Scans (Maven und Gradle) kostenlos ausprobieren: https://scans.gradle.com/ ⬢ Mehr Informationen zu Gradle Enterprise: https://gradle.com/

Slide 60

Slide 60 text

Vielen Dank! Twitter: @marcphilipp E-Mail: marc@gradle.com