We Halved Go Monorepo CI Build Time

Re:We Halved Go Monorepo CI Build Time by spion on Sunday June 26, 2022 @10:56AM (#31884564)

I've worked with both models, and the monorepo model has been far more demanding in terms of time and resources to maintain as you push past the limits of the available tools one by one. Standard build tools go out of the window almost immediately (lots of work to wrap everything with Bazel), then standard collaboration tools (GH) and so on. A dedicated tooling team becomes a must.

What helps maintain polyrepos sane

1. A healthy methodology for dependency management

Evolve APIs with deprecations. Decide on a healthy amount of time for a deprecations to live. Set up alerts when deprecations reach certain amount of time. Set up dashboards (e.g. Grafana) to track dependencies. Help other teams update, and think about how to make updates less painful.

2. Define good boundaries and API contracts to adhere to. The most important thing for a good API contract is stability.

3. Don't prematurely split into microservices. Better ideas for stable API contracts emerge the longer you can wait.

[ Parent | on HN ]

Re:We Halved Go Monorepo CI Build Time by physicsguy on Sunday June 26, 2022 @01:55PM (#31886182)

The issue comes when business requirements don’t allow you to arbitrarily decide that your API should be deprecated. If it’s depended on by 10 teams who are doing higher impact customer facing work than you are, at some point you’re likely to hit a “no” when it comes to disrupting them.

[ Parent | on HN ]

Re:We Halved Go Monorepo CI Build Time by spion on Sunday June 26, 2022 @02:29PM (#31886536)

How is that different in a monorepo? Would you be tasked in implementing the changes for those teams yourself? If so, why not just do that as PRs in their repos?

[ Parent | on HN ]