Download as PDF, PPTX
Uploaded byMike McGarr
Dependencies, distributed code and engineering velocity
The document discusses challenges faced by engineers at Netflix regarding shared code, versioning, and dependencies in a distributed environment. It outlines the difficulties of managing semantic versions and the complexity of consuming libraries, while also presenting potential solutions like adopting a monorepo approach and distributed refactoring. Ultimately, it aims to address how to improve engineering velocity and reduce consumer pain in software development.
More Related Content
Similar to Dependencies, distributed code and engineering velocity
![YTD Video Downloader Pro Crack [Latest 2025]](https://cdn.slidesharecdn.com/ss_thumbnails/distributedapps-250330185247-48b75da1-250407083333-1c55faec-thumbnail.jpg?width=640&height=640&fit=bounds)
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
Dependencies, distributed code and engineering velocity
- 1. Dependencies, Distributed code and engineeringvelocity Mike McGarr @SonOfGarr © J. Michael McGarr, 2017
- 2. I have aproblem... © J. Michael McGarr, 2017
- 3. ...that impacts everyengineer at Netflix. © J. Michael McGarr, 2017
- 4. Affects you too. ©J. Michael McGarr, 2017
- 5. I don't knowthe solution. © J. Michael McGarr, 2017
- 6. direction © J. MichaelMcGarr, 2017
- 7. So what isthis problem? © J. Michael McGarr, 2017
- 8. SHARED CODE© J. MichaelMcGarr, 2017
- 9. cloud microservices © J.Michael McGarr, 2017
- 10. © J. MichaelMcGarr, 2017
- 11. © J. MichaelMcGarr, 2017
- 12. client libraries © J.Michael McGarr, 2017
- 13. © J. MichaelMcGarr, 2017
- 14. transitive dependencies © J.Michael McGarr, 2017
- 15. © J. MichaelMcGarr, 2017
- 16. consuming libraries should be easy©J. Michael McGarr, 2017
- 17. software isn't static ©J. Michael McGarr, 2017
- 18. semantic versions © J.Michael McGarr, 2017
- 19. © J. MichaelMcGarr, 2017
- 20. (*) 3.1.13 3.1.14 3.1.15 3.1.16 3.2.0 3.2.1 3.2.2 3.2.3 4.0.0-RC1 © J.Michael McGarr, 2017
- 21. Which version isgood? © J. Michael McGarr, 2017
- 22. © J. MichaelMcGarr, 2017
- 23. (*) 3.1.13 ❌ 3.1.14❌ 3.1.15 ❌ 3.1.16 ✔ 3.2.0 ❌ 3.2.1 ❌ 3.2.2 ✔ 3.2.3 ❌ 4.0.0-RC1 ❓ © J. Michael McGarr, 2017
- 24. © J. MichaelMcGarr, 2017
- 25. Semantic versioning isinsufficient © J. Michael McGarr, 2017
- 26. © J. MichaelMcGarr, 2017
- 27. © J. MichaelMcGarr, 2017
- 28. Which version ofguava will you get? © J. Michael McGarr, 2017
- 29. © J. MichaelMcGarr, 2017
- 30. © J. MichaelMcGarr, 2017
- 31. Pinning versions is technicaldebt © J. Michael McGarr, 2017
- 32. Just give mea version that works!© J. Michael McGarr, 2017
- 33. consuming libraries is actually hard©J. Michael McGarr, 2017
- 34. Well, at least publishing isthe easy, right? © J. Michael McGarr, 2017
- 35. Need to changefoobar-client:3.2.2 → Bug fix? 3.2.3 → Behavior change? 3.2.0 → API change? 4.0.0 © J. Michael McGarr, 2017
- 36. Who will Ibreak? © J. Michael McGarr, 2017
- 37. Who is consuming mylibrary? © J. Michael McGarr, 2017
- 38. Who is usingthis API that I want to change? © J. Michael McGarr, 2017
- 39. Publishers lack organization-wide visibility © J.Michael McGarr, 2017
- 40. There are solutions out there... ©J. Michael McGarr, 2017
- 41. Option #1: Just dealwith pain © J. Michael McGarr, 2017
- 42. Option #2: Share nothing ©J. Michael McGarr, 2017
- 43. Option #2: Share nothinglittle © J. Michael McGarr, 2017
- 44. Option #3: Monorepo © J.Michael McGarr, 2017
- 45. → all codein a single repository → source integration → head is production → no versions → atomic API changes → lock step deployments © J. Michael McGarr, 2017
- 46. constraints © J. MichaelMcGarr, 2017
- 47. monorepo depends ongates © J. Michael McGarr, 2017
- 48. © J. MichaelMcGarr, 2017
- 49. Our approach... © J.Michael McGarr, 2017
- 50. Can we getthe benefits of a monorepo, without the constraints? © J. Michael McGarr, 2017
- 51. Publisher feedback Managed source Distributedrefactoring © J. Michael McGarr, 2017
- 52. Publisher feedback © J.Michael McGarr, 2017
- 53. Astrid Niagara © J. MichaelMcGarr, 2017
- 54. © J. MichaelMcGarr, 2017
- 55. © J. MichaelMcGarr, 2017
- 56. © J. MichaelMcGarr, 2017
- 57. I now knowwho I will break! © J. Michael McGarr, 2017
- 58. Managed source © J.Michael McGarr, 2017
- 59. eliminate reduce consumer pain ©J. Michael McGarr, 2017
- 60. © J. MichaelMcGarr, 2017
- 61. © J. MichaelMcGarr, 2017
- 62. Shorten adoption curve ©J. Michael McGarr, 2017
- 63. Give me a versionthat works!© J. Michael McGarr, 2017
- 64. Distributed refactoring © J.Michael McGarr, 2017
- 65. Gradle Lint © J.Michael McGarr, 2017
- 66. How do I Changemy API across hundreds of repos? © J. Michael McGarr, 2017
- 67. 1. Find allrepositories 2. Find all API calls 3. Refactor all API calls 4. Issue pull requests en masse © J. Michael McGarr, 2017
- 68. experimental © J. MichaelMcGarr, 2017
- 69. Publisher feedback Managed source Distributedrefactoring © J. Michael McGarr, 2017
- 70. "Eventually consistent distributedmonorepo" -- Avi Bryant (Stripe) © J. Michael McGarr, 2017
- 71. Will this work? ©J. Michael McGarr, 2017
- 72. Thank you Mike McGarr @SonOfGarr mmcgarr@netflix.com ©J. Michael McGarr, 2017