问题
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?
回答1:
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.
回答2:
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.
回答3:
We have not used submodules; What we have done is branching strategy
Every micro-service has its own folder under base_folder folder.
There is a release branch --> currently one master ( this has everything) There is an interface branch --> interfaces ( this has only interfaces like for example protobuffer/ grpc files for all services) . This branch is always merged to master
Each service has a branch --> sprint_service_name where code is pushed (for code review ) and a merge request created to master branch
Code flow
For new component
git checkout interfaces
git checkout -b sprint_service_name
(create branch from interface branch)
For existing component
git checkout sprint_service_name
git fetch origin interfaces
git merge origin/interfaces (don't use git merge origin interfaces !!)
(or for above two steps git pull origin interfaces)
Here is a Developer flow
Push to sprint_service_name branch and create merge request to master branch
git push origin sprint_service_name
Branch flow
sprint_service_namexxx --> Merge Request --> master
sprint_interfaces --> Merge Request --> Interfaces -->master
interfaces --> sprint_service_namexxx (by all, every day)
All common parts will be in interfaces branch
(you can have any number of private branches; But be careful not to merge of master into sprint_service_name or master into interfaces ; else unwanted files will be in your branch)
Pros Each micro service will have only its code and interfaces folder
Cons
I have seen that the below flow does not always happen ideally, like
sprint_interfaces --> Merge Request --> Interfaces -->master
It is more like
sprint_interfaces --> Merge Request --> master
Which means that someone has to manually take Interfaces folder from master and merge to Interfaces branch. But this is just a discipline thing and has not broken anything
回答4:
- Create repository on github
- git clone repository on local machine
- Create projects within repository and commit -> push the projects within the repository
回答5:
You should have only one repo for the entire project whether it's big or small.
You can refere 12 Factor Application for building such project which handles most of the things from here.
Concept of the 12 Factor application is for large project which have many microservices.
来源：https://stackoverflow.com/questions/30286443/microservices-how-to-store-source-code-of-many-microservices