That Randy Brown

One Repository

In both enterprise and startup environments, I've found myself leading, driving, or delivering on destructuring initiatives: initiatives that were meant to take a monolithic application or codebase and destructure it into individual component parts, services, and frontends. I have loved these initiatives. At a previous job, I fell into the trap of pattern propagation and even recommended one. This is probably one of the clearest points of evolved thinking that came out of my time working on Studio Anvil.

When we started building Studio Anvil, we gave nearly everything its own repository. When I started winding things down, we had tens of repos between three engineers. This grew out of a common pattern of one repo per microservice, one repo per frontend, one repo per platform or infra component. But in the last year of Anvil, I started unwinding all of those repositories, bringing them back together. We were a small team of three, and having all the repositories and pipelines was both time expensive--we had to make commits to multiple repositories, push changes, deploy changes, test changes, push new changes--and actual cost expensive--all those pipelines cost money.

After Anvil, I've spent the last year consulting with companies and contracting, and I've worked out of one repo, creating directories for different components. This provides a clean way to add code, delineate when pipelines should run, and makes the work easier to manage for engineers because they only pull and push one repository.

I mostly recommend this for new startups these days--especially for side hustlers and solopreneurs. A single repo is easier to create and manage, to add contributors to, and to maybe eventually transfer ownership to another organization (and out of the personal account). With good discipline (or a willingness to throw things away--either works), the project can be split when it makes sense to, but doing so for a team of 1–3 people might be premature optimization.