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

101–110 of 232 posts

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

#101

Post by mjr00 »

gnarlouse wrote: post #58
sethammons wrote: post #17

people talk about "one change, everywhere, all at once." That is a great way to break production on any api change. if you have a db and >2 nodes, you will have the old system using the old schema and the new system using the new schema unless you design for forwards-backwards compatible changes. While more obvious with a db schema, it is true for any networked api. At some point, you will have many teams. And one of…

I think I disagree. We have a monorepo, we use automated code generation (openapi-generator) for API clients for each service derived from an OpenAPI.json generated by the server framework. Service client changes cascade instantly. We have a custom CI job that trawls git and figures out which projects changed (including dependencies) as to compute which services need to be rebuilt/redeployed. We may just not be at sc…

Monorepo vs multiple repos isn't really relevant here, though. It's all about how many independently deployed artifacts you have. e.g. a very simple modern SaaS app has a database, backend servers and some kind of frontend that calls the backend servers via API. These three things are all deployed independently in different physical places, which means when you deploy version N, there will be some amount of time they are interacting with version N-1 of the other components. So you either have to have a way of managing compatibility, or you accept potential downtime. It's just a physical reality of distributed systems.

> We may just not be at scale—thank God. We a small team.

It's perfectly acceptable for newer companies and small teams to not solve these problems. If you don't have customers who care that your website might go down for a few minutes during a deploy, take advantage of that while you can. I'm not saying that out of arrogance or belittlement or anything; zero-downtime deployments and maintaining backwards compatibility have an engineering cost, and if you don't have to pay that cost, then don't! But you should at least be cognizant that it's an engineering decision you're explicitly making.

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

#103

Post by talos »

teekert wrote: post #99
talos wrote: post #92

Earlier quoted context omitted.

Yeah it reads like it, and if a random AI detector (GPTZero) is to be believed it's pretty much all AI generated. Crazy that nobody can be bothered to get rid of the obvious AI-isms "This isn't just for...", "The Challenges (And How We Handle Them)", "One PR. One review. One merge. Everything ships together." It's an immediate signal that whoever wrote this DGAF.

Pff the mental list of what I can’t use when I write is getting pretty big. Em dashes are done for, as are deep dives, delving, anything too enthusiastic, and Oxford commas… A text either has value to you or it doesn’t. I don’t really understand what the level of AI involvement has to do with it. A human can produce slop, an AI can produce an insightful piece. I rely mostly on HN to tell them apart value-wise.

Did this not read as AI generated to you?

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

#104

Post by nlh »

johnfn wrote: post #70

This post is obviously (almost insultingly) written by AI. That being said, the idea behind the post is a good one (IaC taken to an extreme). This leaves me at a really weird spot in terms of how I feel about it.

It's weird it looks like only a small % of comments on here have caught on to the obvious LLM-ness of it all (I missed it the first go-around but on second read, you're is absolutely correct).

I'm wondering once the exceedingly obvious LLM style creeps more and more into the public mind if we're going to look back at these blog posts and just cringe at how blatant they were in retrospect. The models are going to improve (and people will catch on that you can't just use vanilla output from the models as blog posts without some actual editing) and these posts will just stand out like some very sore thumbs.

(ps all of the above 100% human written ;)

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

#105

Post by b40d-48b2-979e »

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…

    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."
I don't see how this is any different from most projects where keys and the like are kept in some form of secrets manager (AWS services, GHA Secrets, Hashi Vault, etc.).

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

#106

Post by talos »

lawrjone wrote: post #98
talos wrote: post #92

Earlier quoted context omitted.

Yeah it reads like it, and if a random AI detector (GPTZero) is to be believed it's pretty much all AI generated. Crazy that nobody can be bothered to get rid of the obvious AI-isms "This isn't just for...", "The Challenges (And How We Handle Them)", "One PR. One review. One merge. Everything ships together." It's an immediate signal that whoever wrote this DGAF.

I hadn't come across GPTZero before and wondered if it worked. Just testing on a sample of my blog posts (I do one each year) I got a 100% AI generated mark for a post in... 2022, and 2023. Both before AI tools were around. Not to say this post isn't AI generated but you might want a better tool (if one exists)

Hmm I'm curious which blog post tripped it? I tried a few from your site in 2023 and none of them were flagged as AI generated.

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

#107

Post by 0xbadcafebee »

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?

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

#108

Post by mattbillenstein »

trevor-e wrote: post #65
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.

Good luck getting 100+ devs to all use the same logical commit style. And if tests fail in CI you get the inevitable "fix tests" commit in the branch, which now spams your main branch more than the meaningful changes. You could rebase the history by hand, but what's the point? You'd have to force push anyway. Squashing is the only practical method of clean history for large orgs.

This - even 5 devs.

Also rebasing is just so fraught with potential errors - every month or two, the devs who were rebasing would screw up some feature branch that they had work on they needed and would look to me to fix it for some reason. Such a time sink for so little benefit.

I eventually banned rebasing, force pushes, and mandated squash merges to main - and we magically stopped having any of these problems.

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

#109

Post by sallveburrpi »

TheGRS wrote: post #50
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.

Not everyone develops and commits the same way and mandating squashing is a much simpler management task than training up everyone to commit in a similar manner.

We also do conventional commits: https://www.conventionalcommits.org/

Other than that pretty free how you write commit messages

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

#110

Post by conartist6 »

tedmiston wrote: post #76
bulbar wrote: post #11

Earlier quoted context omitted.

My impression is that the world moved on from multirepo to monorepo and I vaguely remember that git submodules have some serious gotchas.

https://diziet.dreamwidth.org/14666.html#what-is-wrong-with-...

yeah, I dunno how else to say it except that if this feature worked right people would like it
Post reply on HN