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

Stripe's Monorepo Developer Environment

blog.nelhage.com

Post reply on HN
Print view View original

101–110 of 249 posts

Re: Stripe's Monorepo Developer Environment

#101

Post by draw_down »

p-o wrote: post #93

It's always so enlightening to have articles like this one shed light on how companies at scale operate. It goes without saying that many of the problems Stripe faced with their monorepo isn't application to smaller businesses, but there are still bits and pieces that are applicable to many of us. I've been working on an ephemeral/preview environment operator for Kubernetes( https://github.com/pier-oliviert/sequencer…

Right, dev boxes do not need to do double duty as a personal computer plus development target, which allows them to more closely resemble the machine your code will actually run on. They also can be replaced easily, which can be helpful if you ever suspect something is wrong with the box itself - if the new one acts the same way, it wasn't the dev box.

I don't recall latency being a big problem in practice. In an organization like this, it's best to keep branches up to date with respect to master anyway, so the diffs from switching between branches should be small. There was a lot of work done to make all this quite performant and nice to use. The slowest part was always CI.

Re: Stripe's Monorepo Developer Environment

#102

Post by chaosphere2112 »

delhanty wrote: post #29

>Some caveats: It’s been nearly five years, and I have no doubt that I have misremembered some of the specific details, even though I’m confident in the overall picture. I’m also certain that Stripe has continued evolving and I make no claim this document represents the developer experience at Stripe as of today. Are there any more recently ex-Stripe folks here willing and able to comment on how Stripe's developer en…

I was only there in 2022, but at that point there were in fact three or more monorepos (forked roughly based on toolchain - go and scala in one, primarily Ruby in the one detailed here, and there was one for the client stripe api libs that was JS only. There may have been more.

Re: Stripe's Monorepo Developer Environment

#104

Post by crabbone »

NB. What the article describes isn't a developer environment in the cloud. It's testing in the cloud. The editor in their model lives on the programmers' laptops, the editing happens there as well and so on. The code is deployed to cloud infrastructure for testing.

Re: Stripe's Monorepo Developer Environment

#105

Post by otabdeveloper4 »

crabbone wrote: post #98
n0us wrote: post #69

Earlier quoted context omitted.

You're limited by the resources available to you on your local laptop and when you close that laptop the dev environment stops running. Remote dev environments are more costly and complicated to maintain but they can be shared, can scale vertically (or horizontally) on demand, can persist when you exit them, and managing access to various internal services from dev environments can in some cases be simpler. It also c…

Not even once did I want to share my dev. environment, nor did anyone want to share mine. We are talking about 25-odd years of being a developer. Never in my life did I want to scale my dev. environment vertically or horizontally or in any other direction. Unless you work on a calculator, I don't know why would you need that. I have no problems with my environment stopping when I close my laptop. Why is this a proble…

> For overwhelming majority of programming projects out there they fit on a programmer's laptop just fine.

What? No. You live in a very sheltered world, my friend.

Re: Stripe's Monorepo Developer Environment

#106

Post by shepwalker »

spacemonkey92 wrote: post #12
KolmogorovComp wrote: post #4

> In addition, Stripe’s monorepo was (to our knowledge) the largest Ruby codebase in existence Bigger than shoppify's?

I also wonder how they handle merge requests in a monorepo, especially when it comes to the code review process.

Hi! I work at Stripe on this. What're you curious about?

Re: Stripe's Monorepo Developer Environment

#107

Post by otabdeveloper4 »

eadmund wrote: post #67
stavros wrote: post #9

Earlier quoted context omitted.

Nix is the right tool for this, developing a tool to make Nix's UX easier is a great idea. Thanks for this!

> Nix is the right tool for this Or Guix, which has the advantage of a more pleasant language.

That's, like, just your opinion, man.

Scheme and/or Lisp is literally the worst language choice for this problem domain.

Re: Stripe's Monorepo Developer Environment

#108

Post by otabdeveloper4 »

1oooqooq wrote: post #52
stavros wrote: post #28

Earlier quoted context omitted.

You mean Docker? They tend to rot much more than I'd like, mostly because you forget to pin something at some point. With Nix, you can't forget.

did the word rot change meaning recently? pin is what causes rot, not what solves it.

Good luck with your Docker containers in three years. (You're gonna need it.)

Re: Stripe's Monorepo Developer Environment

#109

Post by tail_exchange »

jcmfernandes wrote: post #85
nkohari wrote: post #74

Earlier quoted context omitted.

I spent 4.5 years at Stripe, and left in March. The biggest difference not mentioned is the article is that code is no longer kept on developer machines. The sync process described in the article was well-designed, but also was a fairly constant source of headaches. (For example, sometimes the file watcher would miss an update and the code on your remote machine would be broken in strange ways, and you'd have to reco…

Thanks for this. Can you share the experience of those who don't use VS Code?

IntelliJ is also supported. If you want to use something else, like VIM, then you need to ssh into the remote devbox machine. They have support for custom dotfiles, so you can set up your cool VIM environment for all your remote devboxes.

If you don't want remote devboxes, the regular devboxes still work. You just need to deal with the additional pain for syncing the files.

Re: Stripe's Monorepo Developer Environment

#110

Post by bhuga »

delhanty wrote: post #29

>Some caveats: It’s been nearly five years, and I have no doubt that I have misremembered some of the specific details, even though I’m confident in the overall picture. I’m also certain that Stripe has continued evolving and I make no claim this document represents the developer experience at Stripe as of today. Are there any more recently ex-Stripe folks here willing and able to comment on how Stripe's developer en…

Some important differences from 2019:

* Code is off of laptops and lives entirely on the dev server in many (but not all) cases. This has opened up a lot of use cases where devs can have multiple branches in flight at once.

* Big investments into bazel.

* Heavier investment into editor experiences. We find most developers are not as idiosyncratic in their editor choices as is commonly believed, and most want a pre-configured setup where jump-to-def and such all "just work".

Post reply on HN