At CodeSandbox, we run your code in our cloud infrastructure, configure the environment for you and keep your code always ready, behind a shareable URL. Give it a try with this Next.js example or import your GitHub repo!
As an engineer, working at a tech product company comes with the privilege of understanding customers and being able to empathize with your users. Their struggles are most likely your struggles as well. And when you have the unique opportunity to empower them through your work, the reward is tenfold.
Even before I joined CodeSandbox back in 2020, I was fascinated with small and medium-sized team workflows and code collaboration. Engineering is never a solo effort. Working in a team, having other eyes on your code and bringing in non-engineering roles into the discussion are all vital for the success of the product.
The current state of code collaboration
Code collaboration happens around git, branches and pull requests. And while all of these are battle-proven and have their strengths, they also come with some drawbacks.
Git is great for storing and versioning code, but with no tooling around, it is still a pull-based mechanism for collaboration. It is your responsibility to check if the remote version of the repository has updates. Also, your local branch can get out of sync with the remote target branch whenever someone else pushes some changes.
Branches on top of the git model are a great way of separating code changes into different work streams. But local development forces you to point to a single branch. This can become a burden when working in a bigger team where constant review and integration are needed. Checking out a different branch can result in any number of errors: build or runtime crashes, invalid dependencies, and so on. It also adds the inconvenience of having to stash or commit your code to avoid losing changes.
Finally, pull/merge requests are the backbone of code reviews and work integration. Yet git providers offer only a static version of the code and require you to switch back and forth between the platform and the code environment / browser dev server. Unless you use plugins or integrations between your systems, code reviewing requires a switch of environment.
Enter cloud development
Over the past 2 years our team has been working on a new CodeSandbox experience, a cloud-based environment, readily available, sharable, and super friendly for collaboration and work integration.
And while it was still a beta product, we’ve been successfully using it for the past 18 months. Here’s how it helped us collaborate more and improve our workflows.
Each branch with a unique environment
Instead of having an environment for each user, we flipped the model to build the environments around branches. This facilitates collaboration, as branches are searchable and shareable via a URL. Now anyone can jump between environments without affecting their work in progress.
This model allows us to work on multiple features in parallel. It also allows us to collaborate on the same code changes async, without the fear of conflicts or outdated versions of the same branch.
Automated git flows
One of the most frustrating git experiences is to branch out from
main and then hours later find out that you branched from an older commit. This can lead to git conflicts and can get you off track very fast as you have to focus on solving the git problem before your actual project work.
So we decided to optimize some common git flows. Whenever you branch out, we make sure you branch from the latest version of the remote branch. Our git integration also shows you when you need to pull the target branch because of new commits upstream. It also automatically pulls the remote branch in case someone else works on the same branch in another environment.
These flows are especially nice for distributed teams. I often leave my work in progress overnight and when I pick it up in the morning I immediately notice I’m behind the target branch.
Reviews and comments in the code editor
Since the branch has its own environment, we are also supporting PR workflows in the same environment. Once a PR is created, the same branch link can be used to ask for code reviews. The PR diffs allow you to see the changes, add comments and submit a review summary. All this while running dev servers, tests or any other tasks. This lowers context switching and allows our team to easily flip between code reviews and development.
But also this helped other team members get involved in the review process. We often have colleagues from product, design or marketing getting involved in the PRs, as exemplified in the video below.
Showcase of some of our PR review features.
A new default
It’s interesting how developing the cloud development experience took us closer to using cloud development for work. It got to the point where most of our team members (including myself) have a hard time switching back to a local development.
I’m super excited about the prospect of more teams adopting cloud development. It might not be the right solution for everyone, but it definitely is a huge productivity booster for us. Also, using CodeSandbox to build CodeSandbox is an experience on its own, but that’s a story for another time ;)