“Codespaces helps developers to focus on what matters most—building awesome things”

GitHub has made Codespaces available to Team and Enterprise Cloud plan. What positives can teams see from using Codespaces and how will it improve their workflows?

Cory Wilkerson: Codespaces provides software teams a faster, more collaborative development environment in the cloud. By providing developers with fast cloud developer environments, GitHub Codespaces enables teams to perform everything from full-time development, pair programming, PR reviews, and learning/prototyping, without needing to worry about any setup or being limited by location or device.

GitHub engineers can now bootstrap their dev environments in the cloud in less than 10 seconds. This was a process that could take up to 45 minutes.

Now that GitHub uses Codespaces for their own engineering team, what has the process been like? How much time does the engineering team save now?

Cory Wilkerson: GitHub engineers can now bootstrap their dev environments in the cloud in less than 10 seconds. This was a process that could take up to 45 minutes.

There are a few productivity wins. The first is knowing there’s always a known-good environment standing by. So if for some reason your environment degrades, you know you can click a button and provision a new environment. Environments may break for various reasons a few times a month per engineer, and with over 600 engineers committing to github/github in August, that’s a lot of time saved.

Next, you can work on multiple branches or projects in parallel without having to accommodate changes to your local environment. Again, we can assume at least a few times a month an engineer has had to make some local changes to accommodate changes in a branch and/or project. Codespaces helps developers to focus on what matters most—building awesome things.

Finally, we can optimize our environments: prime caches, seed test data, prepare docs, warm our language server, etc. Hard to quantify the time and value returned but this is work that we’ve removed from every developers’ workflow and prebuilt into Codespaces.

To put that into perspective, we chatted with some of our lead engineers at GitHub, and they’re spending around 10 hours a month addressing environment friction. At GitHub’s scale, that could be thousands of hours a month dealing with churn.

SEE ALSO: Five Data Models for IoT: Managing the Latest IoT Events Based on a State in Apache Cassandra

What is under the hood of Codespaces? What tech does it run on?

Cory Wilkerson: We’ve built the core Codespaces experience on top of cloud-based analogs of local primitives along with some core libraries/utilities —such as compute, storage, containers, virtual machines, git, and of course VSCode. The magic with Codespaces is our efforts in making the user experience cohesive, intuitive and fluid as possible, while reducing any friction that might take away from that experience.

How can developers use Codespaces locally on their own machines?

Cory Wilkerson: While Codespaces run in global data centers, you can support a container-based development model locally using VS Code Remote Containers. GitHub Engineering maintains an internal image that we can use in VS Code Remote Containers or vanilla Docker if our engineers need to work offline.

Part of understanding code is establishing context in a familiar setting (your IDE, for instance) — the github.dev experience delivers exactly this experience.

What are the steps involved in migrating to using Codespaces?

Cory Wilkerson: Everyone’s path onto Codespaces will be different. Simple apps will be easy to migrate. Apps that are more complex and haven’t already made the leap to Docker will be more nuanced, but it’s absolutely achievable.

You can find an explainer of how GitHub’s Engineering team moved to Codespaces on our blog, but at a high level, here are a few options for teams to consider.

1. If you’re already using Docker for development, it’s a short hop.
   • You can publish your base codespaces image and reference it in devcontainer.json. Read more on access to container registries here.
   • You can specify a Dockerfile in devcontainer.json
2. If you’re not already using Docker, you can use any of the prebuilt images on vscode-dev-containers.
3. If you don’t specify anything in devcontainer.json, we default you to a “kitchen sink” image where you have access to some of the most popular frameworks (and full access to the container).

SEE ALSO: HTTP 404, freedom not found

JAXenter: What about github.dev? How can this feature change how developers work?

Cory Wilkerson: github.dev is a continuation of our vision for Codespaces, providing teams with a faster, more collaborative development environment in the cloud. WIth github.dev, you press . on any repo and you’re suddenly browsing repo or pull request contents in a fully-functional VSCode experience directly in the browser, no cloning required.

Part of understanding code is establishing context in a familiar setting (your IDE, for instance) — the github.dev experience delivers exactly this experience.

JAXenter: Finally, could you share any future plans for Codespaces with us? What is the GitHub team currently working on, how the project will evolve, or what improvements are on the roadmap?

Cory Wilkerson: We’re excited to roll Codespaces out to more folks and are focused on making the service faster and more reliable. We hope to share more in the near future.