Code Base management for Multitenant Application
Single Github Repository vs Multiple Repositories
This article is an outcome of our experience in working with multi-tenant applications for customers. Lately, we have been working on a SaaS based enterprise level application. The biggest challenge we faced here was source codebase management as per tenant-directed (customer/enterprise) codebase change requirements.
All major discussions revolved around a prime decision:
Should everything be placed in a single github/svn repository or be maintained in separate repositories (tenant wise)?
General comparisons are commonplace. That is why, to answer this pertinent, recurring query, we have attempted to document the use of single repository and multiple repositories, as per area of work and project phase. First, let us summarize for the record, both repository types:
1. Single Repository: Single codebase for all customers.
2. Multiple Repository: Separate codebases for every customer.
Now onto the context-based comparison that details the use of single repository and multiple repositories:
| Area of Work/Phase | Multiple Repository | Single Repository |
|---|---|---|
| Design/Architecture (Based on current architecture) | No need to work on current architecture.Can be replicated as it is. Time Required: will take relative lesse time for configuration changes, environment setup and other minor changes. (depends on the project running stage and complexity) | Architecture change required to adapt multi-tenant requirement, call required on design patterns as well. Time Required: Will take longer time. |
| Requirement Analysis, Approach Decision | Less time required. | More time required. |
| Implementation/Development | Advantages:
| Advantages:
|
| QA and UAT Testing | Advantages:
| Advantages:
|
| Deployment | Advantages:
| Advantages:
|
| Database (Customer wise DB) | Possible | Possible |
Approach Selection Criteria
The following two factors were of prime importance in deciding between single repo and multiple repo:
i) Customization Depth: What functionality customization level are we expecting?
ii) Number of Customers: How many customers targeted/expected for this platform?
Check our comparative graph out based on these two parameters:
Below points are indicative of low customization depth
- UI changes (Angular, HTML, CSS, JS).
- Minimal Server changes which will have less impact on application code and third party plugins (if any).
- NO Domain Specific changes expected
- NO API response level changes expected
Customization depth varies as per your framework and code architecture. Therefore you should be able to define or set an expectation around this.
Summary
I hope the article will further help your judgement in choosing between a single repository and multiple repositories.
You are welcome to respond with your own suggestions and tips as comments to this blog.
