Our project involves developing two major Parts of software:
* Front-end GUIs
* Back-end REST-Api
When we develop, our source code management (SCM) version control system (VCS) is git.
We need to choose how we use git to organize our code.
The top-level choice is to organize as a "monorepo" or "polyrepo" or "hybrid":
* Monorepo means we put all pieces into one big repo
* Polyrepo means we put each piece in its own repo
* Hybrid means some mix of monorepo and polyrepo
For more please see https://github.com/joelparkerhenderson/monorepo-vs-polyrepo
### Decision
We will use a monorepo for a centralized organization of our code and faster development.
### Status
Decided. Open to revisiting if/when new tooling becomes available for managing monorepos and/or polyrepos.
## Details
### Assumptions
All the code that we're developing is for one organization's offerings, and not for the general public.
### Constraints
Constraints are well-documented at https://github.com/joelparkerhenderson/monorepo-vs-polyrepo
### Positions
We considered monorepos in the style of Google, Facebook, etc. We think any monorepo scaling issues are so far in the future that we will be able to leverage the same practices as Google and Facebook, by the time we need them.
We considered polyrepos in the style of typical Git open source projects, such as Google Android, Facebook React, etc. We think these are the best choice for general public participation (e.g. anyone in the world can work on the code) and individual availability (e.g. the project is used on its own, without any other pieces).
### Argument
We choose a monorepo, since it stores all parts of the code in one single place. Every dev instantly knows where to find code and can develop faster. Also DevOps is easier when all the code is stored in a monorepo.
### Implications
CI+CD could take more time for a full build for a monorepo, because CI+CD could build all the projects in the monorepo.
If an organization/team/project grows, then a monorepo will have scaling issues.
Monorepo scaling issues may make it increasing valuable to transition to a polyrepo.
Transition from monorepo to polyrepo is a signficant devops task, and will need to be planned, managed, and programmed.
## Related
### Related decisions
No related decisions.
### Related requirements
We need to develop the CI+CD pipeline to work well with git.
### Related artifacts
We expect the repo organization to have related artifacts for provisioning, configuration management, testing, and similar devops areas.
### Related principles
Easily reversable. If the monorepo doesn't work in practice, or isn't wanted by leadership, it's simple to change to polyrepo.
Customer Obsession. We value getting the project in the hands of customers, and we believe that a monoreop can get us there faster than a polyrepo, and also help us iterate faster.
Think big. Google and Facebook are very strong advocates for monorepos over polyrepos, because all the core offerings can be developed/tested/deployed in concert.
