Introduction

This is a 6-years-later follow-up post to The Best of Two Worlds with Gradle Composite Builds.

The Backup Story

Since the beginning of my Mobile Developer career in 2013 up until 2017, I worked on:

  • Many little Android Apps developed in the span of 1 to 6 months which were, in the best case maintained, but never expanded otherwise (no new features)
  • One little Android Library (SDK) distributed privately to exactly 1 client
  • One moderately sized codebase built by a team of 3 Android Developers

And all that experience led me to write that post, and I think those situations could still benefit from using Composite Builds so that article is still somewhat relevant.

But from 2017 up to this day, I’ve gotten the chance to work on much bigger codebases, and to be a part of much bigger Android Teams:

  • An app with a huge codebase app which existed already for 7 years prior to joining, and I worked on it for 4 years, together with around 10 other Android Developers
  • An app with an already big codebase that will exponentially grow in the future (this startup exists only for around two years) in a team of 8 Android Developers

That’s where I stand now, so I’d like to give an update on that!

Monorepo is a good thing

Of course, let’s start by saying that every situation has its own requirements, and you should organize your code in the best way that fits your organization needs.

But in a big team setting, where all are working on the same codebase things need to move fast, and you want to be as dynamic as possible. In that situation, I would recommend against separating your code into different Git Repositories thus working with one Git Repository only, aka a Monorepo.

Yes, there I said it, a Monorepo is a good thing.

A Monorepo allows you to NOT have to deal with internal versioning which adds a lot of complexity and headaches to your codebase. This is especially true if you have a growing number of modules (aka Gradle Subprojects) in your code, which would multiply your number of headaches exponentially, would you chose to use internal versions per module.

Conclusion

Nowadays, I would recommend working with a Monorepo and organizing your modules into four root folders: libraries, services, features and apps.

More on that later, hopefully before a 6 years long tech-writing hiatus…

Stay tuned!