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