Fighting chaos in a monorepo Monorepo is a good servant, but a bad master
Slide 2
Jakub Beneš Engineering Manager @ Productboard
@jukben
@jukben
https://jukben.codes
Slide 3
Agenda •
What is monorepo
•
What problems we faced at Productboard
•
What strategies we have deployed
•
Takeaways
Slide 4
What’s monorepo
Slide 5
fi
Why and why not? Pros
Cons
• • •
• • •
Better visibility and collaboration across teams Simpli ed dependency management Easier large scale refactoring
Build pipelines VSC Tooling Challenges Limitations Around Access Control
Slide 6
Slide 7
Throwback
85% bigger
Slide 8
Throwback
Slide 9
CI/CD Pipeline
Slide 10
Slide 11
Tooling is our friend We have conducted research for tooling which would help us to maintain the monorepo better. Manage a complex dependency graph
•
Build only a ected projects
•
Provide API sca old code
ff
•
ff
•
Slide 12
Tooling is our friend
Slide 13
Nx proven to be right choice •
We started to break down our monolith into smaller chunks (Nx projects)
•
Possibility to run them separately (eslint, jest, build, deployment)
•
Isolation
•
Ownership
https://medium.com/productboard-engineering/
Slide 14
Adoption 🚀
Slide 15
Slide 16
This is what we have got…
Slide 17
Bene t no. 1: Context Aware Pipeline
•
Nx has also support for distributed caching across all environments
ff
By using nx affected we were able to run only that code that changed or was a ected by dependency graph
fi
•
Slide 18
fi
Bene t no. 1: Context Aware Pipeline
Slide 19
Bene t no. 1: Context Aware Pipeline
75%
fi
faster
Slide 20
Bene t no. 2: Consistence and ownership
By default we push author to make entry into CODEOWNER le
fi
•
fi
Every lib is generated with sane default values and con guration
fi
•
Slide 21
Bene t no. 3: Migration framework
Nx has support of “generators” to sca old tests, components and le structure in general Comes with opinionated structure but it’s extensible
fi
ff
•
fi
•
Slide 22
Cherry on the top: Observability •
Together with CODEOWNERS we are able to map Nx projects to ESlint issues, test coverage and more.
https://medium.com/productboard-engineering/
Slide 23
Next, what else do we have…
Slide 24
Danger.js •
Danger runs during your CI process, and gives teams the chance to automate common code review chores.
•
Make robots do chores! 🤖
Slide 25
Kodiak
•
Trunk based development
•
Integration on feature branch
•
Make robots do chores! 🤖
https://github.com/chdsbd/kodiak
Slide 26
Github Annotations
Developers like to ignore CI outputs, bring it closer….
Slide 27
Bundle Size •
Stay on top of bundle size
•
Bundle size budgets
•
Warn you in case you bundle something huge
Slide 28
Takeaways •
Monorepos are not easy – at some scale you need dedicated team for it
•
If the setup is right, it speeds up things – especially if your codebase is interconnected. Tooling has great impact. Nx proven to be great for our use case.
•
You don’t need to be FAANG to have a swag.
Slide 29
Slide 30
Thank you!
Slide 31
Q&A •
https://nx.dev
•
Scaling monorepo — to in nity and beyond!
•
How we measure adoption of a design system at Productboard https://danger.systems/js/
•
https://github.com/chdsbd/kodiak
fi
•
Jakub Beneš Engineering Manager @ Productboard @jukben @jukben https://jukben.codes