7

My team is planning a migration from subversion to git. We support 3 applications... 1 is primarily for internal users, 1 is for corporate "partners" and 1 is for end users. These applications share some code and also communicate with each other using web services and message queuing. They have different release schedules.

Currently they each have separate subversion repos (so 3 repos). We use the subversion "externals" feature to share the code, including the "contracts" for message queuing.

How should we go about deciding whether to keep the 3 repos when we move to git, using submodules or some other repo sharing technique, or whether we should adopt a monorepo?

  • 3
  • 1
    @gnat, I had seen that question, but I am having trouble applying that very general advice to my specific situation. (However I feel that my specific situation is still common enough that the question should not be closed :) – JoelFan Feb 15 '16 at 15:25
  • 3
    If you can't figure out how to apply the answers to that project then you probably should not try changing until you can figure them out. Those answers are good, and there's not enough info in your question for us to hand-hold you through your migration. Besides, I'd say most people have a single SVN repo. – gbjbaanb Feb 15 '16 at 15:42
  • 1
    "They have different release schedules.", thus different branching schedules, this mean a single repo is not adapted with git – AProgrammer Feb 15 '16 at 16:15
5

My 2 cents: I'd put them in different repos.

  • it's easier to track changes (history, blame...)
  • it's easier to deal with different release cycles (tagging, version branching...)
  • it's easier to deal with (less merges, less branches, no files/dependencies from other projects...)

...as for your "shared code", I'd place it in a lib of its own, in a repo of its own. Or, if it's just about interfacing, declare one project as a dependency of another.

1

TL;DR: I am a consultant working for a government client. We are using submodules for some of our packages. It's quickly becoming frustrating. If you're used to thinking of your packages as being the thing you branch and commit, it's probably not that big of a deal to stick with three repos + submodules.

With that said, if things start to grow and evolve...

This seems a more personal preference question. I think it comes down to two primary things (as I am currently investigating doing this myself).

  1. Information architecture.
  2. Code promotion strategy.
  3. Private versus public modules.

The project I am putting under consideration started as a monolithic application (I really dislike this term) using Laravel. As it grew, I broke into down into services, which I then put into a folder within the overarching application:

- /app
- /app-internal-packages

Then the project reached a point where the Laravel application didn't really contain any custom code; so, I pulled all the services out into separate modules. Some public and some private.

This worked pretty well, except now I needed a way to quickly mimic packagist (or do something else interesting) when developing locally. Further, there's not a lot of sane documentation around using Composer (the package manager for PHP) with public and private repos...at least not sane in my mind. Ticket tracking terrors - each repo has its own set of tickets and my users aren't going to know which service to put the tickets in on GitHub...hopefully you get the idea. Separate repositories can and do work under certain circumstances. Here's what we have now - the notation is [PrR] = Private Repo and [PuR] = Public Repo (change "site" to "application" for your case):

Private repos:

  • site one
  • site two
  • site three
  • site four
  • internal point system
  • newsletter system
  • trainer system
  • conference system

Public repos:

  • authentication package
  • policy display system
  • ui styles and interactions package
  • payment system
  • profile system
  • super universal code
  • ui package
  • markup builder
  • policy docs
  • event registration

Regarding some of the public repos, they are only public because it was so annoying (or costly) to keep them private, that we decided to re-engineer them in such a way as to make them public.

The benefit, of course, is that now all four sites can share that code. But I'm starting to question the reality of that situation, because of our code promotion strategy. Essentially, if it gets used twice in the same scope, promote it to the highest level of that scope (if that makes sense). So, for example, the super universal code started inside one of the sites. it got promoted to the highest level of that site (global, for lack of a better term), then someone wanted it in another site; so, we chucked it in there.

What we're considering moving to:

Private repo:

  • sites
    • site one
    • site two
    • site three
    • site four
  • internal point system
  • newsletter system
  • trainer system
  • conference system

And possibly pulling some of the public repos back into being private. No need to worry about submodules or package management. Code promotion doesn't result in going to a different repo entirely. No build step necessary when doing local development. Launching the latest version of all the apps is a git pull and possible public package update for all the sites. And, each domain name can just point to a sub-folder inside of one of the site directories.

In other words, there's a lot of benefit to going the monorepo route. There's alos a lot of benefit to going the route you are considering. And, even though there is a little more detail in the question, as a coach and a consultant, I don't think there's enough to give a canonical answer or advice.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.