re: Is Your Team Wrong About Your Codebase? Prove It. Visually. VIEW POST

re: What would be your take on moving such a set of applications to a mono-repo with build process for the different deployment applications. I've been...

Just so I understand in broad strokes, are you talking about having a mega-codebase to rule them all, and then having individual builds that plucked only the dependencies they need to advance them through promotion to production?

If so, (1) I'm kinda fascinated and (2) the first thing I'd wonder about would be the impact on the build and unit test suite. I'm inferring from "jars" that this is a Java codebase, and you'd have partial compiling as an option.

Your understanding is correct. It was an idea that I'd read before and seemed pretty interesting, but I've not seen it mentioned anywhere else. I'll have to do some more research, and may have to do some build experiments to make sure that I can actually pull off what I'm considering.

Hmm... it's an interesting proposition, I'd say. Putting my code/data consultant hat back on, I think the questions that would pop into my head for evaluation would be:

  • What is the feedback loop impact of developer time for compiling/running the app/running the test suite?
  • To what extent does the approach facilitate unnecessary coupling?
  • What is the counter-balancing efficiency/time savings in orchestration around a lot of little codebases, maintenance/management-wise?
  • Would it create a spike in merge conflicts?

Then I'd try to figure out ways to quantify projections about those things. (This was basically the essence of my niche practice -- define the important questions, quantify, and make a case.)

code of conduct - report abuse