Azure Tips and Tricks

TIP

🦄 Checkout my Twitch Azure Developer Streaming (opens new window)!

📺 Watch the video : Use Azure Dev Spaces to collaborate with a team on Kubernetes (opens new window).

💡 Learn more : Azure Dev Spaces (opens new window).

# Important: Azure Dev Spaces is retired as of May 15, 2021. Customers should use Bridge to Kubernetes (opens new window).

# Part 3 - Use Azure Dev Spaces to collaborate with a team on Kubernetes

# Working with a team on a container-based solution

This is part 3 of a 3-part series about Azure Dev Spaces (opens new window). In part 1, we learned how to get started with Azure Dev Spaces and in part 2, we developed a multi-service application that runs in multiple containers.

So far, we have been the only developer for the solution. But often, we would be working on a solution in a team of multiple developers. Working on containers in a team can be difficult. Traditionally, each developer would have to create a local development environment and run all containers that make up the solution locally. Or you would set up a separate environment in Azure and use that for development. Both options require a lot of resources and maintenance and make it difficult to stay in sync with the work of the team.

Azure Dev Spaces offers a solution for working with a team on a container-based solution. It provides the concept of a space, which allows you to work in isolation, and without the fear of breaking your team members.

Here is how it works: In Kubernetes (in our case, Azure Kubernetes Service (opens new window), you can have multiple namespaces. Within a namespace you can deploy and run many services that make up a complete solution. In this case, our solution consists of the webfrontend that calls the mywebapi. They are both in the namespace called dev. When I want to work on the mywebapi service, without disrupting the rest of the team, I can set up a new namespace called tipsandtricks and run the mywebapi in there and make changes. Now, I can call the changed mywebapi from the webfrontend in the dev namespace, because Azure Dev Spaces routes everything together for me. Azure Dev Spaces is the magic ingredient that makes this easy. And because Azure Dev Spaces is enabled for these namespaces, we simply call them spaces from now on. Let's try it out.

# Prerequisites

If you want to follow along, you'll need the following:

# Set up a baseline

If you have followed the steps in part 1 and 2 of this series, you are already running the webfrontend and mywebapi in a namespace called default. We are going to create a new space called dev, that we will use as the baseline for our development. This will be the place that contains the latest, stable version of the services, that everybody in the team uses.

  1. You should have the Azure Dev Spaces sample application (opens new window) on your local machine. Clone or download it if you don't have it anymore
  2. Open a command prompt and enter the following command to create the dev space:
azds space select --name dev
1
  1. When you are asked to select a parent space, select <none>
  2. Now navigate to the webfrontend directory (located in the sample application at samples/dotnetcore/getting-started/webfrontend) and execute the following command to deploy the app to the dev space:
azds up -d
1
  1. Navigate to the mywebapi directory and execute the following command again:
azds up -d
1

The baseline is now set up in the dev space. You can check to see what the URI of the webfrontend in the dev space is by executing:

azds list-uris
1

The result will look like this:

(The URIs of the services in dev)

# Develop and test in your own space

Now that we have a baseline, we can set up our own space to work in:

  1. In the command prompt, create a new space by executing the following:
azds space select --name tipsandtricks
1
  1. When asked if you want to select a parent space, select the dev space
  2. Open the mywebapi directory in VS Code and navigate to the ValuesController.cs file.
  3. In the ValuesController, change the Get(int id) method to this:
    public string Get(int id)
    {
        return "The API says something new";
    }
1
2
3
4
  1. Now run the API by pressing F5 or typing azds up in the terminal window of VS Code

The new version of mywebapi is now deployed to the dev/tipsandtricks space. You can see that it is running and what the URIs look like by executing azds list-up and azds list-uris, like in the image below:

(The list of services and URIs after changing the mywebapi)

Mywebapi is now running in the dev/tipsandtricks space. The version running in dev is still running but it is not listed. And the public access point URL for webfrontend is prefixed with tipsandtricks.s. This URL is unique to the dev/tipsandtricks space.

Test it out by opening a URL and navigating to the public endpoint of webfrontend (with the tipsandtricks.s prefix). You'll see the results of the changes in mywebapi, like in the image below:

(The result of the changes in mywebapi)

Now remove tipsandtricks.s from the URL and reload the page. Now, you see the baseline version of mywebapi that is running in the dev space.

# Conclusion

Azure Dev Spaces (opens new window) makes it easy to develop applications on Kubernetes (opens new window). It creates a fast develop-deploy-debug cycle and it removes the need to create an elaborate local development infrastructure. And Azure Dev Spaces also works very well for developers working in teams, because its concept of spaces and because its routing features make it easy to work in isolation without having a complete environment or mocking dependencies. You can learn more about how Azure Dev Spaces works here (opens new window). Go and check it out!

←
Tip 234 - Availability Zones for your Kubernetes cluster in Azure →