Menu
Currently, I have 20 microservices for one project. And every microservice stored in separate GIT reposotiry. Subsequently, the number of services will increase to 200 (or more).
Every service has unit tests and integration tests. Every service has build in TeamCity (Continuous integration server).
Question: How to store source code of 200 microservices for one project? In one repository or in separate repositories?
814
Perhaps the most obvious strategy for a microservices project is to put each microservice and each shared library into a separate repository. Then set up the CI and CD pipelines for each repository, where every repository represents a unit of deployment.
The general guideline in microservices is to not share code. Things that can be shared are libraries that don't changed very often like US States, color, etc. To answer your question what about the code for the communication between the microservices , I would say not to share this code.
The API is necessary for the microservice architecture to function because the API is the communication tool between its services. Without an API, there would be a lot of disconnected microservices. Technically, the microservice would just build to be a monolith again.
A monorepo removes barriers and silos between teams, making it easier to design and maintain sets of microservices that work well together. Standardization. With monorepos, it is easier to standardize code and tooling across the teams.
Unless those micro-services are tightly coupled (meaning it wouldn't make sense to download only some of them, and you would only work with all of them), keeping them each in a separate Git repo is recommended.
But you can still reference them as submodule in a parent repo in order to keep track of their state at any given time.
129
git submodules and subtrees have their own problems too. Facebook and google? have a single repository for all their microservices. There is no clear answer to this problem but things such as refactoring, dependency management and project set up get benefits from a mono repository. Again, the coupling of the services and how different teams interact with the repo is key to choose one or another.
34
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
