Consider a bitbucket project with 3 separate repos, A, B, C
. These form the components of a microservices application, APP
. We'd like to safely try out a monorepo pattern and see if it streamlines the codereview/deployment process. Ideally these would be replaced by a single repository APP
that has subrepos (or modules) A, B, C
.
App
- A
- B
- C
However, we need to do this in a safe way such that the existing repos are migrated one at at a time, or even better, are still independently operable (ie. there is both repo A
and monorepo component A
at same time.
So my biggest fear is that I do this wrong and brick our repos. To avoid this, I've theorized some approaches:
1. Fork each repo (A,B,C) and add the forks to the monorepo - keeping dual complete separation and duplication. We would then migrate development incrementally into monorepo, service-by-service.
2. Some magical git settings that would push commits to two places on the remote? Both to the standalone repo and to the monorepo? Then we could create the entier monorepo in bitbucket, update our remotes, and have changes go to both places as a pilot.
Whateve the solution, our build system is tied to the individual repos, so we have to do the migration gradually (service-by-service). There's no way we could setup this monorepo, and "switch over" in one blast. In reality, there are 40 or so services and its too risky.
Anyone ever done this or have suggestions?