From Dev Portal to Coding in One Click

Today we move yet another small but significant step in our journey in creating the ideal environment for our developers, by enabling developers to locate a particular project in our developer portal, and with one click, open the project in Coder.

Backstage is an important part of our plans to build a developer portal. It's designed to be the main entry point for developers to locate the entire ecosystem of development code and artifacts in the organization.

The Experience

So when a developer access the Backstage portal, he sees a list of Components that our organization owns and has cataloged. How the components were cataloged in the first place will be a subject of another post.

Let's say our intrepid developer wants to do some work on the "sample-java" project. He clicks into it and it will show a summary page that explains what the component is about.

There are a lot more details that should be there, but I'll leave that for another post. What's more important today is that there's a section called "Coder Workspaces". In its initial state, you would see something like this:

Clicking on the "Create Workspace" button brings us to the Coder site, to a page where we can configure how much resources we want to allocate to our workspace and the Git credentials to clone the source code into the workspace.

After submitting the form, Coder kicks off a process to create a workspace in our Kubernetes cluster. And by the end of the process. we get a working environment where a developer can immediately start coding.

The source code for our sample-java project is already conveniently cloned into the workspace, and there's no need for the developer to install any JDK for the project to compile either. In fact, I could immediately run a mvn clean compile after opening the workspace terminal.

The Plumbing

So what's the sauce that allows this magic to work?

It start off with the Coder template. We use a Kubernetes DevContainer template pre-configured to be deployed into our Kubernetes cluster.

And our sample-java source code repository also has further hints that enable the integration to work:

First item of interest is the "catalog-info-yaml" file. The contents of the file provides information that will is populated into the Backstage component page.

And if you look carefully, it also has a "coder" section that described the Coder template to be used along with the Git URL where the source code is to be cloned from.

Another area of interest is the "..devcontainer" folder. Dev Container is an open specification for configuring containers to be used in IDEs such as VS Code. If we click into that folder, it will reveal a set of further configurations that specifies how the container is to be setup to be able to build this particular project.

This particular devcontainer configuration was copied from a reference Java setup in the Dev Container Github repository.

Not all is right though

So is the overall experience good for developer? I wouldn't say so yet.

As I had mentioned before in a previous post, one of my key metrics is the speed that a developer can get productive. And in this case, the process of building the devcontainer itself took almost 10 minutes, mainly due to the time taken to install the OpenJDK libraries.

And even after the initial build, if the workspace gets killed or shutdown, turning it back on again goes through the same process as the initial devcontainer build.

It's tolerable if we do this only once a day when the developer starts work. But if the developer has multiple Java projects and runs multiple workspaces, I can foresee that it will become a productivity killer.

Ah well, just another thing to fix, I guess.

Summary

All in all, I would still consider this a successful next step towards our platform. Next would be to setup the Backstage templating and scaffolding system to create greenfield projects right in Backstage.

Thanks to Vichayuth Okaranee for his good work in setting up the Coder and Backstage.