Stripe's Monorepo Developer Environment
blog.nelhage.com
Stripe's Monorepo Developer Environment
1–10 of 249 posts
Re: Stripe's Monorepo Developer Environment
#2We've been building https://devenv.sh for that reason, I expect more companies to go back to local development once they see DX has improved locally.
Re: Stripe's Monorepo Developer Environment
#3I chatted to Nelson when I was designing brisk (https://github.com/brisktest/brisk) and his insight informed the development of it.
Among other things, Brisk allows you to run tests for your local code changes in the cloud (basically the pay mini test piece but for any test runner)
We also have a sync step much like the one described here and allow users to run one off commands (linters, tsc etc)
Re: Stripe's Monorepo Developer Environment
#4> In addition, Stripe’s monorepo was (to our knowledge) the largest Ruby codebase in existence
Bigger than shoppify's?
Re: Stripe's Monorepo Developer Environment
#5We've been building https://devenv.sh for that reason, I expect more companies to go back to local development once they see DX has improved locally.
How is this better or different from tools like dev which use docker
Re: Stripe's Monorepo Developer Environment
#6I chatted to Nelson when I was designing brisk ( https://github.com/brisktest/brisk ) and his insight informed the development of it. Among other things, Brisk allows you to run tests for your local code changes in the cloud (basically the pay mini test piece but for any test runner) We also have a sync step much like the one described here and allow users to run one off commands (linters, tsc etc)
Can't you achieve all that just using a build system with reliable remote builds & caching e.g. Bazel, Buck, Please, etc?
That also avoids hacky sync scripts.
Re: Stripe's Monorepo Developer Environment
#7We've been building https://devenv.sh for that reason, I expect more companies to go back to local development once they see DX has improved locally.
How is this better or different from tools like dev which use docker
It (obviously) leverages Nix, which in turn means the environment is declarative and fully reproducible (not "reproducible" as in docker). Now, you can use just Nix's devShells, but with devenv you have a middleground between just Nix package manager and a full fledged NixOS module system. Basically, write out one line of code - and you've got your Postgres, another one - full linter set up for whatever language you're using, etc.
Re: Stripe's Monorepo Developer Environment
#8> In addition, Stripe’s monorepo was (to our knowledge) the largest Ruby codebase in existence Bigger than shoppify's?
So from a gut feeling that sounds right, finance is a pretty complicated domain with a lot of per vendor interactions, and Shopify outsources their payment stuff to Stripe.
Also on a headcount level, Google tells me Shopify has 3,500 employees to Stripe's 9,500. Obviously neither company is compromised entirely of engineers, so this is a ballpark estimate.
GitHub feels like the real case where there might be a larger codebase. It's in the middle for employees (6,500), but it's existed longer than Stripe (though not as much longer as my gut feeling told me, interestingly)
Re: Stripe's Monorepo Developer Environment
#9We've been building https://devenv.sh for that reason, I expect more companies to go back to local development once they see DX has improved locally.
Nix is the right tool for this, developing a tool to make Nix's UX easier is a great idea. Thanks for this!
Re: Stripe's Monorepo Developer Environment
#10I chatted to Nelson when I was designing brisk ( https://github.com/brisktest/brisk ) and his insight informed the development of it. Among other things, Brisk allows you to run tests for your local code changes in the cloud (basically the pay mini test piece but for any test runner) We also have a sync step much like the one described here and allow users to run one off commands (linters, tsc etc)
Can't you achieve all that just using a build system with reliable remote builds & caching e.g. Bazel, Buck, Please, etc? That also avoids hacky sync scripts.
No you can’t.
They don’t work from your local development env and also work in your CI env.
Mostly Brisk was designed to run your complete test suite on every codes save (ie local save) but it also works great from your CI.
We can run entire test suites in seconds which is performance you don’t get with those systems you named (which are generally for building/compiling)