Kubernetes, GitHub, and DevOps: Putting it all together to increase confidence in PR reviews.

Nick Greenfield
May 29, 2019 · 8 min read

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.

Unfortunately, this process is commonly limited to team members who directly work on that specific part of the application and have context to provide reliable feedback. Additionally, when working with microservice applications, there is minimal visibility of the end to end impact on the application behavior when modifying an individual service.

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.

Prerequisites

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 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

Fork the Azure Dev Spaces sample github repository. Clone your fork and navigate to the dev-spaces/samples/BikeSharingApp/ directory.

Retrieve the HostSuffix for dev

Use the command to show your AKS cluster’s HostSuffix for dev.

Update the Helm chart with your HostSuffix

Open charts/values.yaml 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 and commands to set up and install the sample application on your cluster.

The 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:

Navigate to the bikesharingweb service by opening the public URL from the command. In the below example, the public URL for the bikesharingweb service is

Navigate to the bikesharingweb service by opening the public URL from the command. In the above example, the public URL for the bikesharingweb service is . Select Aurelia Briggs (customer) as the user. Then select a bike to rent.

Notice the image for the bike is using a placeholder. You are going modify it to use an actual image of the bike.

Configure your CI/CD pipeline

Create an Azure Pipelines account by browsing here.

Install the Azure Pipelines app in your GitHub account.

Install the following extension into your Azure Pipelines organization.

In Azure DevOps under Preview features, enable Multi-stage pipelines. The new YAML pipeline feature was announced at the //Build 2019 conference.

Next create an Azure Container Registry. You can follow the steps here. After you create the Container Registry, follow the steps provided here to grant your AKS cluster access to your ACR.

Now we will create Service Connections. You can follow the steps provided here. Below is the list of service connections you need to create.

  • Docker Registry (Azure Container Registry)
  • Kubernetes (Azure Subscription)
  • Azure Resource Manager (Service Principal Authentication)
  • GitHub

After you have created your Service Connections, navigate to Pipelines and create a new Pipeline.

In the next step you will be asked to point to your code repository. Select GitHub and choose the repository you forked earlier.

Azure Pipelines will analyze your repository content and suggest CI/CD templates.

Select “Existing Azure Pipelines YAML file”.

Type the path (samples/BikeSharingApp/Bikes/azds_pipeline.yaml) to the YAML file in the Bikes directory and continue.

Now it’s time to edit the YAML. Consider opening your service connections in a separate tab since you will reference them frequently.

  1. Replace CONTAINER-REGISTRY-CONNECTION-NAME (line 20) with the Docker Registry service connection name.
  2. 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: login server: builddemo.azurecr.io.
  3. Replace KUBERNETES-CONNECTION-NAME (line 26) with the Kubernetes service connection name.
  4. Replace the KUBERNETES-CLUSTER-NAME (line 29) with your AKS cluster name.
  5. Replace the KUBERNETES-CLUSTER-RESOURCE-GROUP (line 32) with your Azure Resource Group name in which you have created the cluster.
  6. Replace the AZURE-CONNECTION-NAME (line 35) with your Azure Resource Manager service connection name.
  7. Replace GITHUB-CONNECTION-NAME (line 38) with your GitHub service connection name.

Please take note of the trigger section which ensures that this pipeline will run only when you make changes to the Bikes service.

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.

Now you are ready to commit the changes to the GitHub repository.

Work in a feature branch and update the code

Create a new branch named bike-images using the command.

When creating branches only use alphanumeric characters, hyphens and periods. Verify you are on the bike-images branch using the command.

Open Bikes/server.js with a text editor and remove lines 233 and 234:

The remaining code should look like:

Stage and commit your changes to the bike-images branch.

Push the bike-images branch to your fork on GitHub.

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.

Navigate to your build pipeline and confirm it has started building the Bikes service.

Once the build pipeline has successfully completed, navigate back to your pull request on GitHub.

Test and interact with your pull request changes

In the most recent build check, click Show all checks.

Open the review app by clicking on Details to the right of the Dev Spaces review app label.

Navigate back to the detail page for renting a bike. Confirm the placeholder image has been replaced with an actual image of the bike.

Now that we have our changes running in a new dev space, this is a great opportunity to include team members such as product managers and designers to look over our changes and provide feedback.

Once the pull request is merged, the build pipeline will trigger and redeploy the parent branch to the parent dev space. In our scenario the master branch is deployed to the dev space named “dev”. You should try this exercise on your own.

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.

Microsoft Azure

Any language.

Microsoft Azure

Any language. Any platform. Our team is focused on making the world more amazing for developers and IT operations communities with the best that Microsoft Azure can provide. If you want to contribute in this journey with us, contact us at medium@microsoft.com

Nick Greenfield

Written by

Microsoft Azure

Any language. Any platform. Our team is focused on making the world more amazing for developers and IT operations communities with the best that Microsoft Azure can provide. If you want to contribute in this journey with us, contact us at medium@microsoft.com

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store