General Availability For Azure Dev Spaces
Last week at Build, we announced general availability of Azure Dev Spaces. This add-on for Azure Kubernetes Service (AKS) enables your team to develop applications with cloud velocity. Run your service in a live AKS cluster and test it end-to-end, without affecting your teammates. Save maintenance time and money by allowing your entire dev team to share an AKS cluster, rather than requiring separate environments for each developer.
Azure Dev Spaces grew out of conversations that we had with companies that have large microservices-based cloud-native architectures. We learned that many of them built their own internal services that enable their developers to rapidly deploy new code to an isolated environment and test in the context of the entire application. These companies invested significant time and effort in building these capabilities. Azure Dev Spaces allows you to bring the same capabilities to your own team with just a few clicks.
In this post, we will show you how to get started with Azure Dev Spaces:
- If you’re a team lead or devops, you’ll learn how to set up your team’s AKS cluster for use with Azure Dev Spaces.
- If you’re a developer, you’ll learn how to run a service inside your team’s shared AKS cluster.
- You’ll also learn how to troubleshoot a bug using the Dev Spaces extension for VS Code. (An extension for Visual Studio is also available.)
Setting up your AKS cluster
Let’s say that you are running all the services that make up your application in an AKS cluster that serves as your team’s integration testing environment.
Then, you can configure the namespace where the services are running as a dev space, which enables Dev Spaces functionality.
Now that you’ve set up the cluster and the application properly, let’s see how individual developers on your team can test their code in the context of the full application using Dev Spaces.
Running a service in AKS
Suppose that a new developer named Jane has joined your team. You have a new feature that you want her to create inside an existing microservice called Bikes.
Traditionally, Jane would write the code for the feature on her local development workstation and do some basic validation of the feature by running the Bikes service locally. Hopefully your team has already invested in some automated integration tests that she can run to further validate that she hasn’t broken anything. But since she’s new to the application and its codebase, she might not feel confident checking in her code until she’s seen it working properly in the context of the full application. Automated tests can’t catch everything, and no one wants to break the team’s dev environment, especially on their first day on the team!
This is where Azure Dev Spaces can make Jane’s first check-in experience easy and positive.
Jane can create a child dev space called newfeature. The parent of newfeature is the dev space you configured when you initially set up Dev Spaces for your team, which is running the entire application.
The version of the application that runs in the child dev space has its own URL. This is simply the URL to the team’s version of the application, prefixed with newfeature.s. Azure Dev Spaces intercepts requests that come in with this URL prefix and routes them appropriately. If there is a version of the service running in the newfeature dev space, then Dev Spaces routes the request to that version. Otherwise, Dev Spaces routes the request to the team’s version of the service, running in the root dev space.
Jane can leverage this functionality to quickly test her changes end-to-end, even before she checks in her code. All she needs to do is run her updated version of the Bikes service in the newfeature dev space. Now she can access her version of the application by using the newfeature.s URL. Azure Dev Spaces will automatically handle routing requests between Jane’s updated version of Bikes (running in the newfeature dev space) and the rest of the services that make up the application (running in the parent dev space).
In the example shown below, the site currently shows a generic bicycle icon for each listed bicycle. One of Jane’s teammates has updated the database to include a picture of the actual bicycle. Jane needs to update the Bikes service to pull this picture from the database and send it along to the upstream services:
Troubleshooting a bug using Azure Dev Spaces
What if Jane discovers her changes didn’t work properly? First of all, her broken code is only running in her newfeature dev space. Her teammates’ requests still use the original version of Bikes running in the parent dev space. She can take her time troubleshooting the problem, knowing that she’s not blocking her teammates.
In addition, she can use the Azure Dev Spaces extensions for Visual Studio or Visual Studio Code to debug her code running live in the cloud with a single click. This allows her to quickly zero in on the problem, fix it, and validate her fix. She can even run and debug additional services inside the newfeature dev space, if the problem spans multiple services.
The following video shows debugging a Node.js service through VS Code, but the same capabilities are available for .NET Core and Java, inside Visual Studio or VS Code:
Once Jane has fully tested her new feature using Azure Dev Spaces, she can check in with confidence, knowing that she has validated her code end-to-end.
Ready to get started?
If you’re ready to increase developer productivity while saving maintenance time and money, check out the documentation to get started with Azure Dev Spaces. The team development quickstart walks you through setting up a realistic multi-service application and then debugging one service in an isolated dev space. You can learn how to set up a CI/CD pipeline to deploy your entire application to a Dev Spaces-enabled cluster so that your devs can easily test their individual services in the context of the entire application. And dive into the article on How Dev Spaces Works if you want to learn all about the magic behind Dev Spaces. (Spoiler alert: There’s not a lot of magic, just a lot of standard Kubernetes primitives!)