TLDR for vscode remote users? Let me be lazy and just get a Y/N over whether it has any benefit over the normal remote vscode UX.
They reimplemented GitHub Codespaces without GitHub
Devpod: Remote development environment at Uber
171–180 of 235 posts
Re: Devpod: Remote development environment at Uber
#172I’m one of the engineers at Coder and we build internal development platforms for a living. Here’s how our team builds Coder with Coder - https://coder.com/blog/how-our-development-team-shares-one-g...
Over at https://GitHub.com/coder/coder you’ll find our source code btw. Essentially we provision software development environments using terraform for Linux,windows,Mac,arm,amd64 and soon FreeBSD…
Re: Devpod: Remote development environment at Uber
#173At my current startup we are doing something similar. Perhaps as inspiration for others without the huge budgets.
From very high level it works as follow:
- developer logs in to AWS cli
- executes: dev/01-start-env.sh
- prepare infra services: dev/02-base-platform.sh
- code can be changed and run locally. But if they need to test in the bigger system: dev/03-deploy-code.sh
There is dev/99-delete-env.sh
An environment is a personal ec2 spot instance that auto shutsdown if there’s no developer activity for over an hour.
The idea is that all developers work (program/code) locally as much as possible. But deploys changes to their own private environment in a much heavier VM’s that runs all services in containers.
Also there is a dev/tests.sh that executes the exact same test cases as in continuous integration. In fact, we try to bring all checks enforced during CI to be available to developers in their semi-remote-dev area environments for quick feedbacks.
Re: Devpod: Remote development environment at Uber
#174Poor Australian devs needing to develop on Oregon with 200ms of latency
Having to develop with circa 360ms pings was a contributing factor to me deciding to leave Gitpod. https://ghuntley.com/tea
Re: Devpod: Remote development environment at Uber
#175Let's face it: monorepos are just huge monoliths. If you want modular software, you WILL have to pay the price of fragmentation. Someone needs to think about the boundaries between different parts of a system. If those boundaries are defined by functions, classes, packages or services, it doesn't matter that much. Yes, it is always a pain. Shipping the entire forest of modules in a single repo seems like a good compr…
Monorepos and monoliths are orthogonal Monorepos are a tooling nightmare. Monorepos are a bandwidth black hole. Monorepos make some things possible that are just not possible or very very hard when you have multiple independent repos that are built and tested independently. Namely, a) they allow you to test the effects of a change on all the components that depend on you, before you merge your change. This reduces th…
You don't need a monorepo to have integration tests. You can very well have a CI that clones a bunch of stuff and builds and tests them all together.
The issue that monorepo is solving is regarding write operations: FOO depends on BAR, which depends on BAZ. If you need to change BAZ to develop what you want on FOO and they're all on multiple repos, you'd have to pull request your way from the bottom to the top of the dependency graph. This is what causes the friction that monorepos avoid, and this is the hard part of such workflow to automate with multiple repos.
Re: Devpod: Remote development environment at Uber
#176Re: Devpod: Remote development environment at Uber
#177Glad to see industry adopting cloud server + ssh + code-server / code-remote as a standard. As a PhD student I have been working on HPCs like this with an environment I built myself for a while. It is really good and helps you to move fast.
It depends on latency. If you have a slow network connection (or are simply far away from the cloud data center) you are in for pain. That being said, running a local environment on a constantly throttling 2019 MacBook Pro that sounds like a jet engine is probably worse.
Re: Devpod: Remote development environment at Uber
#178Can someone explain the rationale behind switching to a monorepo? I just don't get it. Does it mean also having a single unified production environment build? I have been managing a stack composed of 500+ repositories, communicating through webservices, files and ABIs for many years now, and never quite hit much of the issues cited as reasons to switch to monorepos. Having multiple small independent environments for…
I maintain the web monorepo at Uber, so I think I can give some context. Monorepos allows us to centralize important dependency upgrades. E.g. fixing log4j vulns is a lot easier when you can patch everything simultaneously. Same for tzdata (2022g gave very little heads up) Auditing for npm supply chain attacks was a lot simpler in monorepo than microrepos. Etc. Monolithic version control doesn't have to mean monolith…
Thanks for the insights.
> E.g. fixing log4j vulns is a lot easier when you can patch everything simultaneously.
This is true, though the refactoring action done can also be distributed and carried out via automated Pull Request creation to multiple repos. You still will deploy the changes over a period of time with a degree of parallelism.
> We had microrepos before and the main problem is that to this day I still get some random team coming to me for help w/ some rediscovered 7 year old repo that doesn't even build anymore cus lockfiles weren't a thing back then.
You can solve this by forcing a CI build for every repo to be run periodically.
> For us and companies like Google, monorepos work well with our organization model.
What are the concrete aspects of the organization model that make both orgs favor monorepos?
Re: Devpod: Remote development environment at Uber
#179Earlier quoted context omitted.
Monorepo lets me have a _single_ Github PR with the changes across 4 projects in front of me. To replicate what you're talking about in a multirepo setup, you have to introduce changesets in 4 different places, then merge them in the right order, make a bunch of tiny releases, update commit hashes to point to the right one, and do a lot of other bookkeeping because in this house we keep our projects separated.
Indeed, the small additional bookkeeping is the price to pay. I'm quite used to it, so I don't even see it anymore. Is that all? These 5 less minutes of bookkeeping are the killer feature of monorepos? Because, as far as I see it, there's an insane amount of engineering to make a monorepo work even at small scale. Are these 5 minutes per multi-project PR worth it? I wouldn't be surprised these 5 minutes are largely o…
5 minutes? Bit of an underestimation.
Also I used bazel in my previous monorepo setup… so not really paying a huge CI cost.
Re: Devpod: Remote development environment at Uber
#180Earlier quoted context omitted.
I maintain the web monorepo at Uber, so I think I can give some context. Monorepos allows us to centralize important dependency upgrades. E.g. fixing log4j vulns is a lot easier when you can patch everything simultaneously. Same for tzdata (2022g gave very little heads up) Auditing for npm supply chain attacks was a lot simpler in monorepo than microrepos. Etc. Monolithic version control doesn't have to mean monolith…
Thanks for your answer. How does CI work in practice? how do you avoid rebuilding and retesting the whole repo at every change? That would be an insane waste of resource and time.
By only testing and building packages that has a dependency on the changed package.