Developer Productivity Engineering

Software sowie Build und Deployment Prozesse werden mit jedem neuen Feature immer komplexer. Deshalb stellt die schnelle und sichere Auslieferung von neuen Features für viele Unternehmen eine zentrale Herausforderung dar. Sicherzustellen, dass Entwickler in kurzen Zyklen Features entwickeln und deployen können, hat sich deshalb zum - viel zu oft vernachlässigten - Erfolgsfaktor entwickelt. Erfolgreiche Unternehmen geben dieser Aufgabe besondere Priorität durch die Einführung einer neuen Disziplin: Dem Developer Productivity Engineering. Diese Disziplin basiert auf einer Kultur in der die gesamte Entwicklungsorganisation zusammenarbeitet um die Produktivität der Entwickler (engl. "Developer Productivity") zu maximieren. Dieser Talk beantwortet die Fragen:

- Welchen Herausforderungen stehen Unternehmen gegenüber hinsichtlich Developer Productivity?
- Wer ist dafür verantwortlich die Developer Productivity zu maximieren?
- Welche Skills werden im Developer Productivity Engineering benötigt?
- Welche Tools nutzen Teams um die Developer Productivity zu messen und zu verbessern?

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

4. Was macht Gradle Inc.?
   

   View Slide

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

   View Slide

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

   View Slide

7. use at will
   Warum Developer Productivity Engineering?
   

   View Slide

8. 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
   

   View Slide

9. View Slide

10. 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
    

    View Slide

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

    View Slide

12. Software-Entwicklung ist komplex
    ⬢ Toolchain ist komplex mit komplexen Eingaben
    ⬢ Toolchain beeinflusst
    ○ Geschwindigkeit der Iterationen
    ○ Feedbackzyklen
    ○ Zuverlässigkeit des Feedbacks
    ⬢ Effizienz der Toolchain ist der Schlüssel zu kreativem
    Flow und effektiver Zusammenarbeit
    

    View Slide

13. 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 Effizienz der Toolchain
    ○ Vergrößern des Teams hat fast keinen Einfluss mehr
    

    View Slide

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

    View Slide

15. 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
    

    View Slide

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

    View Slide

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

    View Slide

18. Wie überzeuge ich meinen Chef?
    ⬢ Vorteile quantifizieren
    ⬢ Effekt eines Developer Productivity Teams aufzeigen
    

    View Slide

19. 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
    

    View Slide

20. use at will
    Schnelle Feedbackzyklen
    

    View Slide

21. 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
    

    View Slide

22. 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
    

    View Slide

23. 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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

27. 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
    

    View Slide

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

    View Slide

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

    View Slide

30. 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)
    

    View Slide

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

    View Slide

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

    View Slide

33. 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.
    

    View Slide

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

    View Slide

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

    View Slide

36. Änderung eines Implementierungsdetails im Modul “service”
    

    View Slide

37. Änderung eines Implementierungsdetails im Modul “core”
    

    View Slide

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

    View Slide

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

    View Slide

40. 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
    

    View Slide

41. Gradle: Noch schnellere inkrementelle Builds
    ⬢ Inkrementelle Groovy-Kompilierung (seit Gradle 5.6)
    ⬢ File System Watching (seit Gradle 6.5)
    ⬢ Configuration Caching (seit Gradle 6.6)
    

    View Slide

42. 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
    

    View Slide

43. View Slide

44. use at will
    Ohne Daten keine schnellen Builds
    

    View Slide

45. ⬢ 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
    

    View Slide

46. Was passiert mit Performance-Regressionen?
    ⬢ Unbemerkt
    ⬢ Bemerkt aber nicht kommuniziert
    ⬢ Kommuniziert aber nicht behoben
    ○ Ursache zu finden 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
    

    View Slide

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

    View Slide

48. 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
    

    View Slide

49. use at will
    Zuverlässige Builds
    

    View Slide

50. Unzuverlässige Builds und Tests machen
    wahnsinnig
    

    View Slide

51. 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 finden statt an meinen
    Sachen arbeiten
    ○ Alternativ: Build nochmal laufen lassen
    

    View Slide

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

    View Slide

53. Was passiert mit unzuverlässigen Builds?
    ⬢ Bemerkt aber nicht kommuniziert
    ⬢ Kommuniziert aber nicht behoben
    ○ Ursache zu finden 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
    

    View Slide

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

    View Slide

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

    View Slide

56. 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
    

    View Slide

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

    View Slide

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

    View Slide

59. 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/
    

    View Slide

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

    View Slide