Monorepo -vs- Multirepo

the local dev env should die!

A.K.A.

Tradeoffs and tooling of having all the code base in one place

How do you know how to

build, test, run, debug, deploy

a project ?

❌ Monorepo ≠ monolithic app 🧐

It’s about the development workflow 👩‍💻
And sharing surrounding code with colleagues
(build scripts, e2e tests, dependencies, docs, config,…)

Multiple languages ?

Multiple projects ?

What size ?

Everybody should do monorepo?

• mono cloud provider account
• mono k8s cluster
• mono VPC
• mono slack channel
• mono computer (mainframe)
• mono office space (open office)
• mono chair (bench)
• mono coffee machine
• mononucleosis

Monorepo: please don't

@mattklein123/monorepos-please-dont-e9a279be011b

• ✅ Easier collaboration and code sharing
• ✅ Single build / no dependency management
• ✅ Code refactors are easy / atomic commits

❌ scalability

Demo: babel (js)

Inside a monorepo

👉 different levels of abstraction

different levels of abstraction

different levels of abstraction

gitlab: from idea to production

Multirepo

1 microservice = 1 repository

Why microservices ?

👉 to ship your organization

Jeff Bezos 2002:

• All teams will henceforth expose their data and functionality through service interfaces.
• Teams must communicate with each other through these interfaces.
• There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
• It doesn’t matter what technology they use.
• All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
• Anyone who doesn’t do this will be fired.
• Thank you; have a nice day!

credit: Manu Cornet

credit: Manu Cornet

credit: Manu Cornet

credit: Manu Cornet

credit: Manu Cornet

credit: Manu Cornet

tooling

GIT

monorepo with git

• plain git
• git subtree (folder)
• git submodules (black box)
• custom scripts

code storage ≠ deployment

tooling

• splitsh/lite (split monorepo)
• bazel.build (build monorepo)
• lernajs.io (build js monorepo)
• unravelin/tomono (migration)
• korfuri/awesome-monorepo (list of resources)

tooling (cont'd)

Archive git history

git clone file:///Users/$USER/Projects/myProject myClonedProject \
--shallow-since=2016-09-02
    

getting good at monorepo means

1. getting good at git and its internals
2. being disciplined about code reuse and dependencies
3. being disciplined for branches, PR size and documentation
4. implementing features toggle and A/B testing
5. having the whole picture ie. the whole code base on your hard drive (Linux kernel repo is ~20GB)
6. understanding versioning
7. immutable build (uniformity)

Being disciplined relates to engineering culture

What about the developer environment ?

Developer environment

• what's an environment ?
• how to reproduce ?
• how to make changes ?
• code << project code

Dev Env with Git submodules

• opt-in ✌️
• lightweight 🥗
• focus on developers 👩‍💻
• faster onboarding 🙋‍♂️

github blog - submodules

+ github/scripts-to-rule-them-all

demo

IDEA

instead of trying to reproduce locally / mock:

• all the microservices
• all DBs (cluster?)

on your 16GB laptop, why not a

• cloned
• on-demand
• pre-setup

environment ?

Efficient -vs- Effective

# minimalist

gitpod.io

codesandbox.io

in browser editor:

• eclipse/che
• theia-ide/theia