Development teams often collaborate in feature branches and pull requests. When finishing feature branches, developers submit pull requests for review before merging into the application’s main branch. This process works well for static code diffs where newly committed code is reviewed to meet the team’s standards for consistency and maintainability.
With Azure Dev Spaces and Azure Pipelines, you can easily test your PR code in the context of the broader application running in Azure Kubernetes Service(AKS). As a bonus, team members such as, product managers and designers can become part of the review process during early stages of development.
In this guide you will learn how to:
Set up Azure Dev Spaces on a managed Azure Kubernetes Service (AKS) cluster in Azure.
Deploy a large application with multiple microservices to a dev space..
Configure an Azure pipeline that dynamically creates review apps whenever a pull request is created or updated.
If you need help troubleshooting any of the steps in this article visit our issues page on our Github repository.
An Azure subscription. If you don’t have an Azure subscription, you can create a free account.
Azure CLI installed.
Helm 2.13 or greater installed.
Setup an Azure Pipelines account
Set up your AKS cluster
You must create an AKS cluster in a supported region. The below commands create a resource group called MyResourceGroup and an AKS cluster called MyAKS.
Enable Azure Dev Spaces on your AKS cluster
Use the use-dev-spaces command to enable Dev Spaces on your AKS cluster and follow the prompts. The below command enables Dev Spaces on the MyAKS cluster in the MyResourceGroup group and creates a dev space called dev.
Get the sample application
Retrieve the HostSuffix for dev
Use the azds show-context command to show your AKS cluster’s HostSuffix for dev.
Update the Helm chart with your HostSuffix
Open charts and replace all instances of <REPLACE_ME_WITH_HOST_SUFFIX> with the HostSuffix value you retrieved earlier. Save your changes and close the file.
Run the sample application in Kubernetes
The commands for running the sample application on Kubernetes are part of an existing process and have no dependency on Azure Dev Spaces tooling. In this case, Helm is the tooling used to run this sample application but other tooling could be used to run your entire application in a namespace within a cluster. The Helm commands are targeting the dev space named dev you created earlier, but this dev space is also a Kubernetes namespace. As a result, dev spaces can be targeted by other tooling the same as other namespaces.
You can use Azure Dev Spaces for team development after an application is running in a cluster regardless of the tooling used to deploy it.
Use the helm init and helm install commands to set up and install the sample application on your cluster.
The helm install command may take several minutes to complete. The output of the command shows the status of all the services it deployed to the cluster when completed:
bikesharingwebbikesharingwebAurelia Briggs (customer)kubernetes certification training
Consider opening your service connections in a separate tab since you will reference them frequently.
Replace CONTAINER-REGISTRY-CONNECTION-NAME (line 20) with the Docker Registry service connection name.
Replace CONTAINER-REGISTRY-URL (line 23). You can find this information in the Azure Portal under your Azure Container Registry. It should look something like this:
Replace KUBERNETES-CONNECTION-NAME (line 26) with the Kubernetes service connection name.
Replace the KUBERNETES-CLUSTER-NAME (line 29) with your AKS cluster name.
Replace the KUBERNETES-CLUSTER-RESOURCE-GROUP (line 32) with your Azure Resource Group name in which you have created the cluster.
Replace the AZURE-CONNECTION-NAME (line 35) with your Azure Resource Manager service connection name.
Replace GITHUB-CONNECTION-NAME (line 38) with your GitHub service connection name.
There are two stages in the pipeline, and each has a condition which ensures they run only on changes to the master branch or when a pull request is created for master.
Work in a feature branch and update the code
Create a new branch named bike-images using the git checkout command.
$ git checkout -b bike-images
$ git status
On branch bike-images
nothing to commit, working tree clean
// Hard code image url *FIX ME*
theBike.imageUrl = "/static/logo.svg";
var theBike = result;
thebikeid. = theBike._id;
delete theBike._id; res.send(theBike);
$ git add Bikes/server.js
$ git commit -m "Removing hard coded imageUrl from /bikes/:id route"
$ git push origin bike-images
Pull Request Flow
Navigate to your forked repository on GitHub and create a new pull request. The base branch will be master and the branch you are comparing is bike-images.
With the Azure Dev Spaces and Azure Pipelines pull request flow, we have tested our changes before code has been merged into the application’s main branch. By creating a review app for integration testing, team members can confidently approve pull requests by ensuring the new changes will not have a negative impact on other services in the application.