-
We'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.
-
InfluxDB
InfluxDB high-performance time series database. Collect, organize, and act on massive volumes of high-resolution data to power real-time intelligent systems.
-
brisk
Brisk is a complete Continuous Integration tool for executing your test suites. It is designed around speed and only rebuilds the test env when necessary. It can be run either from your developer machine (running your entire test suite in seconds on every save) or as part of your CI/CD pipeline. (by brisktest)
I 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)
-
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) and as I could agree to a lot of things OP said.
I think dev boxes is really the way to go, specially with all the components that makes an application nowadays. But the latency/synchronization issue is a hard topic and it's full of tradeoff.
A developer's laptop always ends up being a bespoke environment (yes, Nix/Docker can help with that), and so, there's always a confidence boost when you get your changes up on a standalone environment. It gives you the proof that "hey things are working like I expected them to".
-
-
Maybe I'm missing something here but couldn't you just track the whole VM setup (dependencies, dev tools, telemetry and everything) in your monorepo? That is, the VM config would get pulled from master just like everything else, and then the developer would use something like nixos-shell[0] to quickly fire up a VM based on that config that they pulled.
[0]: https://github.com/Mic92/nixos-shell (not to be confused with nix-shell)
-
spec
Development Containers: Use a container as a full-featured development environment. (by devcontainers)
Err — sorry I mean https://containers.dev/
Which has pretty nice support across IDEs. For example - https://code.visualstudio.com/docs/devcontainers/containers
I set this up for my last company where we had all sorts of “works on my machine issues” and a needlessly painful onboarding experience. Local development became streamlined with this tooling BUT pre-apple silicon macs couldn’t handle running Docker like this. Glacially slow. We had a python monorepo with a bunch of services within it.
I am curious whether nix is an alternative / improvement for this. Was going down the nix road at first but an infrastructure team member steered me toward devcontainers instead and I’ve been pretty happy since!
-
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.