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

151–160 of 232 posts

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

#151

Post by Denvercoder9 »

bb88 wrote: post #130
gorgoiler wrote: post #114

Earlier quoted context omitted.

If your monorepo compiles to one binary on one host then fine, but what do you do when one webserver runs vN, another runs v(N-1), and half the DB cluster is stuck on v(N-17)? A monorepo only allows you to reason about the entire product as it should be. The details of how to migrate a live service atomically have little to do with how the codebase migrates atomically.

But isn't that a self-inflicted wound then? I mean is there some reason your devs decided not to fix the DB cluster? Or did management tell you "Eh, we have other things we want to prioritize this month/quarter/year?" This seems like simply not following the rules with having a monorepo, because the DB Cluster is not running the version in the repo.

Maybe the database upgrade from v(N-17) to v(N-16) simply takes a while, and hasn't completed yet? Or the responsible team is looking at it, but it doesn't warrant the whole company to stop shipping?

Being 17 versions behind is an extreme example, but always having everything run the latest version in the repo is impossible, if only because deployments across nodes aren't perfectly synchronised.

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

#153

Post by UltraSane »

alemanek wrote: post #120
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.

Here is how I think of it. When I am actively developing a feature I commit a lot. I like the granularity at that stage and typically it is for an audience of 1 (me). I push these commits up in my feature branch as a sort of backup. At this stage it is really just whatever works for your process. When I am ready to make my PR I delete my remote feature branch and then squash the commits. I can use all my granular com…

The "cleaner" commit history should be a separate layer and the actual commit history should never be altered.

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

#154

Post by jtafurth »

UltraSane wrote: post #90
sallveburrpi wrote: post #26

Earlier quoted context omitted.

squash results in a cleaner commit history. at least that’s why we mandate it at my work. not everyone feels the same about it I guess

"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 mean simply running an interactive (or fixup) and leaving only important commits that provide meaningful information to the target branch.

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

#157

Post by nkmnz »

Denvercoder9 wrote: post #142
awesome_dude wrote: post #97

Earlier quoted context omitted.

People that Blue Green are doing that, aren't they? Canary/Incremental, not so much

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.

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

#158

Post by awesome_dude »

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.

The only way I could read their answer as being close to correct is if the clients they're referring to are not managed by the deployment.

But (in my mind) even a front end is going to get told it is out of date/unusable and needs to be upgraded when it next attempts to interact with the service, and, in my mind atleast, that means that it will have to upgrade, which isn't "atomic" in the strictest sense of the word, but it's as close as you're going to get.

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

#159

Post by hju22_-3 »

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?

Agreed. Especially when a lot of people just pick out x, y and z thing as if it's the definitive sign of AI, disregarding the possibility of it being normal outside of their own writing and what they read. Not to mention cultural differences. That certain characters or ways of structuring text have become more pervasive lately is a sign, yes, but it does not mean that the presence of it in a text is anything definitive towards the use of AI.

It's almost as if when you seek to find patterns, you'll find patterns, even if there are none. I think it'd benefit these kinds of people to remember the scientific "rule" of correlation does not equal causation and vice versa.

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

#160

Post by kittoes »

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…

https://dev.azure.com/byteterrace/Koholint/_git/Azure.Resour...

How close do you think this is? Deploys everything but the actual backend/frontend code.

Post reply on HN