Suggestion a Safe Strategy to Migrate to Monorepo

Question

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?

Answer 1

There's another way to do achieve the same, without actually building the monorepo (keeping the original repositories intact). Create a new bare repository ('parent'), then add A, B and C as X-Modules (directories, synced with remote repositories), and work with that new repository as with a regular one. This way you can update all your remote repositories with one push to the parent repository. There's a special app for Bitbucket Server for that. And here's an article that describes the build process.