Monorepo is just one small part of the puzzle. If you want to actually achieve the dream state that is alluded to when someone says "monorepo", you have to be willing to endure a super-deep and honest evaluation of your tech stack and processes.
We have been successfully running a monorepo for ~5 years now using nothing more than the bare-ass GitHub PR process with some basic checkbuilds sprinkled on top. We intentionally avoided getting our hands dirty with CI automation as much as was feasible. Building our software manually is so simple its not really worth dedicating a team to worrying about.
I would say the biggest key to our success was finding a way to minimize 3rd party dependencies. By making certain strategic technical choices, we were able to achieve this almost by default. Our repository is effectively hermetically sealed against outside changes in all of the ways that matter to the business owners. Github providing issues at the repository grain is also a very powerful synergy for us in terms of process - we started using issue numbers as the primary key for all the things.
With regard to technical choices - consider that some languages & ecosystems provide a lot more "batteries included" than others, which provides a substantially different landscape around how many 3rd parties may need to be involved and how.
Same here. We migrated from 5 repositories down to a single one in 2013, and have been working with a simple PR process (first Phabricator, then Bitbucket) ever since, along with a TeamCity as a CI to run tests and deploy.
We do try to minimize our "technological footprint" by reducing the number of languages, tools, third party packages, etc. But I would say our main strategy is to enforce static analysis everywhere. Global type-checking between C# and F# projects comes out-of-the-box (but you have to design the shared types properly), and we produce TypeScript contracts and signatures out of C# contracts and API endpoints.
Strong typing + monorepo is a superweapon in my view.
I enjoy being able to make a change to some common type, open up a "Monorepo.sln" panopticon and instantly see every project/system/service/library/et.al. across the entire organization that would be impacted by the change.
> Building our software manually is so simple its not really worth dedicating a team to worrying about.
I’m curious about this one — do you mean you don’t have an automated build/deploy mechanism? If something is very simple, it’s normally also very simple to automate. A short bash script running in a basic GitHub action is next to no maintenance and saves a lot of time, even if it’s just 5-10 minutes each day.
> do you mean you don’t have an automated build/deploy mechanism? If something is very simple, it’s normally also very simple to automate.
Absolutely. Making things simple also synergizes very well with automation.
We actually have written an in-house system that can build our software and package it up to AWS S3 buckets for final delivery. This is something used more frequently by project managers to create releases for customers. Developers usually prefer to run builds out of VS2022 for the special ad-hoc cases and other non-customer unicorn targets (i.e. internal admin dashboards).
The point is that the whole thing is so simple in aggregate that we don't need engineers spending dedicated time worrying about how it all fits together. One basic msbuild command and you have a release folder you can zip up and send to the customer (or extract to some internal QA system).
I think I get where the parent is coming from -- automatons are a "behind the scenes" thing and can balloon in complexity without realizing it. But if you're forced to perform every step manually with no automation you create natural pressure to avoid doing complex things.
I'm not OP, but we have a similar setup at my company. We actually use C++ as our primary language, with a significant amount of python for testing and glue.
In general, dependencies are included in our repository directly, changing/adding dependencies means getting your dependency in to the repository.
We have been successfully running a monorepo for ~5 years now using nothing more than the bare-ass GitHub PR process with some basic checkbuilds sprinkled on top. We intentionally avoided getting our hands dirty with CI automation as much as was feasible. Building our software manually is so simple its not really worth dedicating a team to worrying about.
I would say the biggest key to our success was finding a way to minimize 3rd party dependencies. By making certain strategic technical choices, we were able to achieve this almost by default. Our repository is effectively hermetically sealed against outside changes in all of the ways that matter to the business owners. Github providing issues at the repository grain is also a very powerful synergy for us in terms of process - we started using issue numbers as the primary key for all the things.
With regard to technical choices - consider that some languages & ecosystems provide a lot more "batteries included" than others, which provides a substantially different landscape around how many 3rd parties may need to be involved and how.