$30 off During Our Annual Pro Sale. View Details »

Developer Productivity Engineering

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.

  2. Marc Philipp Principal Software Engineer bei Gradle Inc. JUnit team

    lead Twitter: @marcphilipp E-Mail: marc@gradle.com Wer bin ich?
  3. Wer ist Gradle Inc.? ⬢ Ursprünglich gegründet als GmbH in

    Deutschland ⬢ Mittlerweile Startup mit Hauptsitz in San Francisco ⬢ Fully Remote
  4. Was macht Gradle Inc.?

  5. ⬢ Gradle User ⬢ Maven User ⬢ Verantwortlich für Build/CI

    Pipeline/Entwicklerproduktivität ⬢ Manager eines Softwareteams Wer sind Sie bzw. seid ihr?
  6. Agenda Warum Developer Productivity Engineering? Schnelle Feedbackzyklen Zuverlässige Builds

  7. use at will Warum Developer Productivity Engineering?

  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
  9. None
  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
  11. Qualität des kreativen Flows + Effektivität der Zusammenarbeit Produktivität des

    Teams
  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
  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
  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
  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
  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
  17. Innovation ⬢ Wettbewerbsnachteil durch geringe Entwicklerproduktivität ⬢ Umsetzungsprobleme von Geschäftsinnovationen

    in Software
  18. Wie überzeuge ich meinen Chef? ⬢ Vorteile quantifizieren ⬢ Effekt

    eines Developer Productivity Teams aufzeigen
  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
  20. use at will Schnelle Feedbackzyklen

  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
  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
  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
  24. Fehlersuche bei langsamen Builds ⬢ Langsamer Build ⇒ mehr Änderungen

    pro Build ⬢ Mehr Änderungen pro Build ⇒ schwierige Fehlersuche ⬢ Speziell auch für CI-Builds
  25. Kosten der Fehlerbehebung Die Zeit einen Fehler zu beheben wächst

    exponentiell mit der Zeit, die benötigt wird, ihn zu erkennen.
  26. Teufelskreis Beispiel: Merge-Konflikte ⬢ Langsame Builds ⇒ mehr Änderungen /

    Build ⬢ Build fixen dauert länger ⬢ Erfolgreiche Builds noch länger ⬢ Mehr Merge-Konflikte
  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
  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
  29. Wie lassen sich Builds beschleunigen? ⬢ Schneller heißt weniger machen

    ⬢ Inkrementelle Builds ⬢ Build Cache
  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)
  31. Build Caching Wenn die Inputs eines Tasks/Goals sich nicht verändert

    haben, können die Outputs eines vorherigen Builds wiederverwendet werden.
  32. Beispiel Java-Kompilierung ⬢ Inputs: ◦ Sourcen ◦ Compile-Classpath ◦ Java-Version

    ◦ Compilerargumente ◦ … ⬢ Outputs: ◦ Kompilierte Klassen
  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.
  34. Änderung an der Signatur einer public-Methode im Modul “export-api”

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

  36. Änderung eines Implementierungsdetails im Modul “service”

  37. Änderung eines Implementierungsdetails im Modul “core”

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

  39. Remote Build Cache ⬢ Beschleunigt Builds für das gesamte Team

    ⬢ Wiederverwendung von Build Outputs zwischen CI Agents und Entwicklerrechnern
  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
  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)
  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
  43. None
  44. use at will Ohne Daten keine schnellen Builds

  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
  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
  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
  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
  49. use at will Zuverlässige Builds

  50. Unzuverlässige Builds und Tests machen wahnsinnig

  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
  52. Verschiedene Fehlerarten ⬢ Verifikationsfehler (gutartig) ◦ Compilefehler ◦ Checkstyle ◦

    Test-Fehlschlag ⬢ Kein Verifikationsfehler (bösartig) ◦ Flaky Test ◦ Repository nicht verfügbar ◦ OutOfMemory während Build
  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
  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
  55. Daten, woher? ⬢ Für Entwicklerbuilds und CI ⬢ Build Scans:

    Lösung in Gradle Enterprise ⬢ Demo: Failure Dashboard
  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
  57. Daten, woher? Test Dashboard: Lösung in Gradle Enterprise

  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
  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/
  60. Vielen Dank! Twitter: @marcphilipp E-Mail: marc@gradle.com