Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything as code: How we manage our company in one monorepo

kasava.dev

Post reply on HN
Print view View original

161–170 of 232 posts

Re: Everything as code: How we manage our company in one monorepo

#161

Post by maccard »

webdevver wrote: post #57
wrs wrote: post #35

This is sort of a whole product , but it’s hardly managing the whole company . Financials? HR? Contracts? Pictures of the last team meeting? It just looks like a normal frontend+backend product monorepo, with the only somewhat unusual inclusion of the marketing folder.

i am actually eagerly waiting for someone to show the real-deal: actually everything in a github repo, including 'artfiacts', or atleast those artifacts which can't be reconstructed from the repo itself. maybe they could be encrypted, and you could say "well its everything but the encryption key, which is owned in physical form by the CEO." theres a lot of power i think to have everything in one place. maybe github c…

At a previous job we put compilers and standard libraries in version control, with custom tooling to pull the right version for what you need.

We used p4 rather than git though.

Re: Everything as code: How we manage our company in one monorepo

#162

Post by awesome_dude »

jtafurth wrote: post #154
UltraSane wrote: post #90

Earlier quoted context omitted.

"squash results in a cleaner commit history" Isn't the commit history supposed to be the history of actual commits? I have never understood why people put so much effort into falsifying git commit histories.

There are several valid reasons to "falsify" commit history. - You need to remove trash commits that appear when you need to rerun CI. - You need to remove commits with that extra change you forgot. - You want to perform any other kind of rebase to clean up messages. I assume in this thread some people mean squashing from the perspective of a system like Gitlab where it's done automatically, but for me squashing can…

> You need to remove trash commits that appear when you need to rerun CI

Serious question, what's going on here?

Are you using a "trash commit" to trigger your CI?

Is your CI creating "trash commits" (because build artefacts)?

Re: Everything as code: How we manage our company in one monorepo

#163

Post by mh2266 »

literallyroy wrote: post #96
Denvercoder9 wrote: post #31

Earlier quoted context omitted.

Squashing only results in a cleaner commit history if you're making a mess of the history on your branches. If you're structuring the commit history on your branches logically, squashing just throws information away.

I’m all ears for a better approach because squashing seems like a good way to preserve only useful information. My history ends up being: - add feature x - linting - add e2e tests - formatting - additional comments for feature - fix broken test (ci caught this) - update README for new feature - linting With a squash it can boil down to just “added feature x” with smaller changes inside the description.

stacked diffs are the best approach and working at a company that uses them and reading about the "pull request" workflow that everyone else subjects themselves to makes me wonder why everyone is not using stacked diffs instead of repeating this "squash vs. not squash" debate eternally.

every commit is reviewed individually. every commit must have a meaningful message, no "wip fix whatever" nonsense. every commit must pass CI. every commit is pushed to master in order.

Re: Everything as code: How we manage our company in one monorepo

#164

Post by doublet00th »

hckr1292 wrote: post #42
doublet00th wrote: post #37

I built something like this at my previous startup, Pangea [1]. Overall I think looking back on our journey I'd sign up for it again, but it's not a panacea. Here were the downsides we ran into - Getting buy in to do everything through the repo. We had our feature flags controlled via a yaml file in the repo as well, and pretty quickly people got mad at the time it took for us to update a feature flag (open MR -> mer…

Did you use turbo, buck or Bazel? Without monorepo tooling (and the blood, sweat, and tears it takes to hone them for your use cases), you start hitting all kinds of scaling limits in CI.

We had python scripts that generated GitLab CI/CD yaml [1]. Tooting my own horn here, but it was super cool to ship fairly fast for the first year or so. By the end, we had something like 5 MB of yaml, but in order for the GitLab SaaS backend to process it, it took something like 32 gigs of ram on their MergeRequestProcessor SideKiq worker.

They had to open a whole epic in order to reduce the memory usage, but I think all that work just let us continue to use GitLab as the number of services we grew increased. They recommended we use something called parent/child pipelines, but it would have been a fairly large rewrite of our logic.

[1]: https://docs.gitlab.com/ci/yaml/

Re: Everything as code: How we manage our company in one monorepo

#165

Post by mrwrong »

0xbadcafebee wrote: post #107
Escapade5160 wrote: post #83

This article reads like 4o wrote it. It's so exhausting not being able to find content produced by a human being.

What's exhausting is seeing people complain about AI writing. What exactly are you looking for instead? A poorly written article?

[dead]

Re: Everything as code: How we manage our company in one monorepo

#166

Post by Denvercoder9 »

nkmnz wrote: post #157
Denvercoder9 wrote: post #142

Earlier quoted context omitted.

Blue/green might allow you to do (approximately) atomic deploys for one service, but it doesn't allow you to do an atomic deploy of the clients of that service as well.

Why that? In a very simple case, all services of a monorepo run on a single VM. Spin up new VM, deploy new code, verify, switch routing. Obviously, this doesn't work with humongous systems, but the idea can be expanded upon: make sure that components only communicate with compatible versions of other components. And don't break the database schema in a backward-incompatible way.

So yes, in theory you can always deploys sets of compatible services, but it's not really workable in practice: you either need to deploy the world on every change, or you need to have complicated logic to determine which services are compatible with which deployment sets of other services.

There's a bigger problem though: in practice there's almost always a client that you don't control, and can't switch along with your services, e.g. an old frontend loaded by a user's browser.

Re: Everything as code: How we manage our company in one monorepo

#167

Post by NeutralWanted »

codegeek wrote: post #38

I have a question about Monorepo. Do companies really expose their entire source code all in one repo for their devs to download ? I understand that people can always do bad things if they want but with monorepo, you are literally letting me download everything right ?

I work at Google, and yes. We use a monorepo for absolutely everything you can think of. But good luck getting that code off a corp device without being caught!

Re: Everything as code: How we manage our company in one monorepo

#169

Post by oooyay »

Eridrus wrote: post #59
lorey wrote: post #30

Earlier quoted context omitted.

Very interesting points. Would you mind sharing a few examples of when cherry-picking is necessary and why atomic changes are a lie? I'm using a monorepo for my company across 3+ products and so far we're deploying from stable release to stable release without any issues.

Atomic changes are a lie in the sense that there is no atomic deployment of a repo. The moment you have two production services that talk to each other, you end up with one of them being deployed before the other.

Atomicity also rarely matters as much as people think it does if contracts are well defined and maintained.

Re: Everything as code: How we manage our company in one monorepo

#170

Post by abustamam »

emptysea wrote: post #89
odie5533 wrote: post #72

Earlier quoted context omitted.

What do you use for feature flags?

Not OP, but I think building feature flags yourself really isn’t hard and worth doing. It’s such an important component that I wouldn’t want to depend on a third party

I agree, but it's hard to get the nuances right. It's easy to roll out a feature to half of your user base. It's a bit harder to roll a feature out to half of users who are in a certain region, and have the flag be sticky on them.

We use Unleash at work, which is open source, and it works pretty well.

Post reply on HN