Dependencies, distributed code and engineering velocity
•
0 likes•537 views
Most software engineers loathe and fear debugging dependency update issues. They are common challenges in the modern enterprise environment. The proliferation of git repositories, the sharing of reusable code and rise of the microservice all conspire to make organization-wide binary integration a nightmare. At Netflix, engineers are not immune to the cost of dependency updates. Library owners publish new versions of their code without a comprehensive understanding of the organizational impact. Application owners ingest new library versions that can fail in obvious or subtle ways, leading to decreased confidence and slower organizational velocity. But these are problems we understand, and tooling can help.
Recommended
Recommended
More Related Content
Similar to Dependencies, distributed code and engineering velocity
Similar to Dependencies, distributed code and engineering velocity (13)
More from Mike McGarr
More from Mike McGarr (15)
Recently uploaded
Recently uploaded (20)
Dependencies, distributed code and engineering velocity
- 1. Dependencies, Distributed code and engineering velocity Mike McGarr @SonOfGarr © J. Michael McGarr, 2017
- 2. I have a problem... © J. Michael McGarr, 2017
- 3. ...that impacts every engineer at Netflix. © J. Michael McGarr, 2017
- 4. Affects you too. © J. Michael McGarr, 2017
- 5. I don't know the solution. © J. Michael McGarr, 2017
- 6. direction © J. Michael McGarr, 2017
- 7. So what is this problem? © J. Michael McGarr, 2017
- 8. SHARED CODE© J. Michael McGarr, 2017
- 9. cloud microservices © J. Michael McGarr, 2017
- 10. © J. Michael McGarr, 2017
- 11. © J. Michael McGarr, 2017
- 12. client libraries © J. Michael McGarr, 2017
- 13. © J. Michael McGarr, 2017
- 14. transitive dependencies © J. Michael McGarr, 2017
- 15. © J. Michael McGarr, 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. Michael McGarr, 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 is good? © J. Michael McGarr, 2017
- 22. © J. Michael McGarr, 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. Michael McGarr, 2017
- 25. Semantic versioning is insufficient © J. Michael McGarr, 2017
- 26. © J. Michael McGarr, 2017
- 27. © J. Michael McGarr, 2017
- 28. Which version of guava will you get? © J. Michael McGarr, 2017
- 29. © J. Michael McGarr, 2017
- 30. © J. Michael McGarr, 2017
- 31. Pinning versions is technical debt © J. Michael McGarr, 2017
- 32. Just give me a version that works!© J. Michael McGarr, 2017
- 33. consuming libraries is actually hard© J. Michael McGarr, 2017
- 34. Well, at least publishing is the easy, right? © J. Michael McGarr, 2017
- 35. Need to change foobar-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 I break? © J. Michael McGarr, 2017
- 37. Who is consuming my library? © J. Michael McGarr, 2017
- 38. Who is using this 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 deal with pain © J. Michael McGarr, 2017
- 42. Option #2: Share nothing © J. Michael McGarr, 2017
- 43. Option #2: Share nothing little © J. Michael McGarr, 2017
- 44. Option #3: Monorepo © J. Michael McGarr, 2017
- 45. → all code in a single repository → source integration → head is production → no versions → atomic API changes → lock step deployments © J. Michael McGarr, 2017
- 46. constraints © J. Michael McGarr, 2017
- 47. monorepo depends on gates © J. Michael McGarr, 2017
- 48. © J. Michael McGarr, 2017
- 49. Our approach... © J. Michael McGarr, 2017
- 50. Can we get the benefits of a monorepo, without the constraints? © J. Michael McGarr, 2017
- 51. Publisher feedback Managed source Distributed refactoring © J. Michael McGarr, 2017
- 52. Publisher feedback © J. Michael McGarr, 2017
- 53. Astrid Niagara © J. Michael McGarr, 2017
- 54. © J. Michael McGarr, 2017
- 55. © J. Michael McGarr, 2017
- 56. © J. Michael McGarr, 2017
- 57. I now know who 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. Michael McGarr, 2017
- 61. © J. Michael McGarr, 2017
- 62. Shorten adoption curve © J. Michael McGarr, 2017
- 63. Give me a version that works!© J. Michael McGarr, 2017
- 64. Distributed refactoring © J. Michael McGarr, 2017
- 65. Gradle Lint © J. Michael McGarr, 2017
- 66. How do I Change my API across hundreds of repos? © J. Michael McGarr, 2017
- 67. 1. Find all repositories 2. Find all API calls 3. Refactor all API calls 4. Issue pull requests en masse © J. Michael McGarr, 2017
- 68. experimental © J. Michael McGarr, 2017
- 69. Publisher feedback Managed source Distributed refactoring © J. Michael McGarr, 2017
- 70. "Eventually consistent distributed monorepo" -- 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