Monorepo is when putting code of several micro-projects in one code repository.
Well, that's the missing part of the micro-service architecture.
Splitting our code into micro-projects, each with its own tests, deployment, scaling, etc., introduces a new challenge of maintaining and using many microcode repositories.
Monorepo will hold the collection of micro-project while sharing the echo system of testing, deploying, etc.
- When your team needs to run fast -> faster -> fastest.
- When there are too many repositories and no one understands what/where they are and if their dependency versions are aligned.
- When small library change follows with 30 PR's on 30 git repositories (was the story of my life).
- When there are a small number of teams working together because when there are a greater number of teams working on the same git repository, it can do worse than better.
- Per micro project build&deploy:
git diffto find out what directory changed
- build&deploy only this part
- Code owners:
- what team is responsible for what part of the code?
- Generate micro project script:
- Creating new microservice should be done in seconds(take a look at https://yeoman.io)
- Each new microservice should be built automatically by the same standard as all other services
- Contract lib:
- All services contracts speak in the same language: Rest/Grpc/etc...
- All services use the same libraries with no duplicate code.
Listen to our CTO, Matan Lachmish, talks about Monorepos on Developing Symptoms podcast (for Hebrew speakers)
Made with ❤️ by Sanga