Soam Vasani, software engineer at internet payment services company Stripe, spoke at QCon, an enterprise developer conference under way in London this week, about why the business is shifting to remote coding. Developers use Visual Studio Code on their desktops to edit code that resides on virtual machines on AWS EC2 (Elastic Compute Cloud).
“All the software we build has a high level of criticality,” he said, explaining that this requirement means the team places a high priority on the accuracy of the development environment versus production. Also highly valued is fast feedback, so that they catch bugs early.
The Stripe codebase, said Vasani, is a “Ruby monolith” with millions of lines of code. Ruby is dynamically typed, and this caused issues early on as some errors could only be discovered by running unit tests to validate the code. “Every developer, when they made a change had to make a trade off. Do I just run the smallest set of tests I can, or do I run all of the tests?”
Dynamic typing also imposed a cognitive load, Vasani said, because “you had to read all the code to figure out what each parameter was … it made people afraid of doing large code changes.”
In 2017 the company started to address this by adding type annotations and building a type checker, an open source project called Sorbet. Sorbet is not just a type checker, but also supports LSP (Language Server Protocol) so that it can parse code and highlight errors in the editor, find definitions and references, and more.
Why is my source code on my laptop?
This was, Vasani said, transformational for the company’s Ruby development; but not enough in itself to meet the requirements of accuracy in the development environment.
Developers are issued with laptops or MacBooks, but these do not exactly match the production environment on AWS. Stripe therefore assigns AWS VMs to developers, which they call devboxes, and a sync service copies code to the devbox whenever it is saved.
A service on the devbox picks up any changes and updates any impacted microservices with the new code, so that developers can test the results on something close to the production environment.
Even this was not enough. There was a problem with branch switching, where lots of code changes at once, causing delays (bearing in mind the large size of the codebase).
Part of the solution was to give developers multiple devboxes, one for each branch, but the team asked themselves, “if we’re running all the backend services on the devbox, if the test database is on the dev box … then why is my source code on my laptop?”
The solution was to use a Visual Studio Code server on the devbox. In this scenario, the code is edited and debugged directly on the remote machine. “What runs on the laptop is the editor UI,” said Vasani, “The server runs whatever extension integrations you need … one nice advantage is that there is no longer any kind of local setup for a developer.
“We can control these dev environments because they’re in the cloud, so we can have the traditional metrics and alerting to make sure everything is working,” he added.