- ABP Framework version: v5.0.1
- UI type: MVC / Blazor
- DB provider: EF Core
- Tiered (MVC) or Identity Server Separated (Angular): Blazor Server Microservices
Hi,
We are just starting a new project and it's based on the microservice template. I would like some guidance about how to organize git source control. i.e.
My thoughts would be to split everything up and use NuGet Packaging to provide dependencies to the other projects. I would really like your opinion on this.
For Example.
Repo 1
- Authentication / Identity Server
Repo 2
- Front End Blazor UI
- Web Gateway BFF
Repo 3
- Public Web Site Front End Blazor UI
- Public Gateway BFF
Repo 4
- Identity Service
Repo 5
- Administration Service
Repo 6
- SSAS Service
Repo 7
- Product/Custom Service
Repo 8
- Other Service
Regards
Toby.
2 Answer(s)
-
0
Hi @thedatacrew Unfortunately, there is no best way that I recommend to you.
There is a lot of factors that affect while deciding mono-repo or multi-repo. For example, the most important one is your team. How do you develop software? Which services will have a dedicated team? There is a lot of questions, and source-control usage defines how you do that job in your way.
But I can highly recommend comparing the pros & cons between mono-repository and mono-repository.
Mono-Repo
Benefits
- Lowers Barriers of Entry (onboarding new developers is easy)
- Centrally Located Code Management
- Painless Application-Wide Refactorings
- More Difficult To Break Adjacent Functionality
- Teams Share Development Culture
Issues
- Slower Development Cycles
- Requires Download of Entire Codebase
- Unmodified Libraries May Be Newly Versioned
- Forking Is More Difficult
Multi-Repo
Benefits
- Independent Library Versioning
- Independent Service Releases
- Helps Define Access Control Across the Organization
- Allows Teams To Work Autonomously
Issues
- Libraries Must Constantly Be Resynced
- May Fragment Teams
Disclaimer: I've just summarized some of the topics from https://kinsta.com/blog/monorepo-vs-multi-repo/#benefits-of-monorepo You can read more about it.
In a summary, I can't say exactly the right thing because there is no single correct answer. Mostly your development cycle and culture define it.
-
0
Hi @Toby,
Our recommended way would be the pragmatic way which suits your development team the best. Your sample makes sense.
