Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Developer Productivity Engineering

Marc Philipp
September 28, 2020

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?

Marc Philipp

September 28, 2020
Tweet

More Decks by Marc Philipp

Other Decks in Technology

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: [email protected]
    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: [email protected]

    View Slide