SonarQube—Azure DevOps Integration

The most important parts of any project are quality and security. While it’s important to have a solid user experience, it’s equally important to maintain security standards. This can be accomplished with SonarQube. This tool can be integrated with Azure DevOps to give you data where you need it, such as in your Pipeline and Pull Requests.

What is it?

SonarQube is a self-hosted code analysis services that detects issues to ensure the reliability, security, and quality of your project. It finds issues in your code and provides guidance on how to best address them. You can also use this tool to add Quality Gates to your CI/CD workflow. If the quality parameters are not passed, the job fails so you can correct it before it rushes into production. Additionally, SonarQube decorates your issues directly in your Azure DevOps Pull Requests, which will help you deal with them sooner. SonarQube is free for open-source projects; you’ll only pay when you start analyzing private repositories. In this article, we will be focusing on the cloud-hosted version of this product called SonarCloud.

How to Integrate with Azure DevOps

Integrating SonarCloud with AzureDevOps is as simple as installing the extension from the Visual Studio Marketplace and following the setup flow on SonarCloud’s website. The flow will ask you for things like your Azure DevOps Organization name and a Personal Access Token. Then, you’ll set up a SonarCloud organization and project, as well as choose a plan for your SonarCloud subscription. If all the repositories you want to analyze are public, you can choose the free plan. You’ll only pay if you analyze a private repo.

Now you’re ready to set up your analysis. To do this, follow the SonarCloud walk-through to set up scanning in Azure Pipelines. This analysis will be done during your build. You can include Quality Gates that will cause the build to fail if it does not pass the quality check. After your build runs, you’ll be able to view the Detailed SonarCloud Report in the build summary. Additionally, you can set up pull request integration that will allow the Azure DevOps UI to display when an analysis build is running. This is done by configuring your build policy in Azure DevOps, as well as giving SonarCloud access to your pull requests. The results are visible directly in Azure DevOps or on the SonarCloud dashboard.

The information provided by SonarCloud and its integration with Azure DevOps is invaluable. Now, you’ll be able to identify and repair issues faster and more efficiently. For more information about SonarCloud, or to get started today, contact our team of experts at PRAKTIK.

Using Terraform with Azure DevOps

Managing infrastructure can be tricky business. Development teams must maintain the settings for each individual deployment environment. Over time, environments can become difficult or impossible to reproduce. This would mean that hard-to-track manual processes would have to be used to create and maintain these environments. Instead of going through this headache, we can use an Infrastructure as Code (IaC) tool called Terraform.

What is Terraform?

Terraform is an open-source IaC tool for provisioning and managing cloud infrastructure. This tool allows users to define a desired end-state infrastructure configuration. It will then go ahead and provision the infrastructure exactly as described. It can also safely and efficiently re-provision infrastructure in response to configuration changes. This means that your infrastructure will be exactly the same every time.

Using Terraform with Azure DevOps

As with many technologies, there is an extension in the Visual Studio Marketplace to make your life easier. To get started, simply install the Terraform extension. This extension provides service connections for AWS and GCP for deployment to Amazon or Google clouds – you’ll need to create an Azure Service Principal if you’re deploying to Azure. It also includes a task for installing the required version of Terraform on your agent, as well as a task for executing the core commands. This extension requires some configuration, such as defining your provider and which command you want the tool to execute.

After your configuration is complete, you are able to include the Terraform task in your Build or Release Pipeline to manage your infrastructure automatically.

For more information about Terraform, or to get started, contact our team of experts at PRAKTIK.





Using Dependabot with AzureDevOps

Technology is ever-changing, which means your repository’s dependencies are, too. Maintaining and updating dependencies is crucial for the security and functionality of your app. Unfortunately, it is a laborious chore that takes away from time that could be spent working on your next project. Dependabot is a tool that can take care of all of this for you.

What is Dependabot?

Dependabot is a GitHub-native tool that can monitor your repository’s dependencies, and even update them. This is done automatically at an interval of your choosing: daily, weekly, or monthly. When the tool identifies a dependency that needs to be updated, it raises a pull request. These pull requests can be for version or security updates. This tool can update versions of dependencies automatically, but security updates must have human intervation.

Integrate with Azure DevOps

It is really easy to integrate Dependabot and Azure DevOps using the free Dependabot extension in the Visual Studio Marketplace. This extension is full of features and easy to configure. All you have to do is run a YAML file. In this file, you can specify your task parameters, such as target branch and package manager. This file is also where you would specify the schedule on which you’d like it to run. Then, give it access to your repository’s Project Collection Build Service and allow it to do things like contribute to pull requests and create branches. Now you’re ready to start having Dependabot do work for you!

To learn more or to get started today, contact our team of experts here at PRAKTIK.

Azure Pipelines for Jira

It is important for a development team to be able to choose which tools work best for them. Jira is a popular bug and issue tracking system. It is also used for requirements and test case management. Azure Pipelines is a powerful CI/CD tool to automatically build, test, and ship your code. What if you want to use both? Azure Pipelines for Jira integrates the two tools to provide a seamless development experience.

Getting Started

Getting started is very simple. To use Azure Pipelines for Jira, you will need to install the extension from the Atlassian Marketplace. The extension will need to be linked to your Azure DevOps organization. Then, you need to enable “report deployment status to Jira” in your release pipeline, as well as provide a map of your deployment stages.

Using Azure Pipelines for Jira

One of the best parts of Azure DevOps is that you are free to integrate with whatever tool is going to make you successful. Azure Pipelines for Jira makes the integration that much easier with bidirectional end-to-end functionality. For example, the integration will add links to Jira issues as work items deployed with Azure Pipelines. It also enables you to view details about your Azure Pipelines deployment directly in Jira issues. Furthermore, you’ll be able to include Jira issues in release notes, as well as track issue delivery in Jira.

To learn more about this integration, or to get started today, contact our team of experts at PRAKTIK.

Run a Self-Hosted Agent Using Docker and Kubernetes

There are many reasons to host your own build agents in Azure DevOps, including cost savings, better control over your agents, and, of course, all the benefits of the cloud. However, private build agents do require their own maintenance. Wouldn’t it be nice to have a short-lived, customized agent ready whenever you needed it? This is possible using Kubernetes and Docker.

Getting Started

Before you get started, you will need Docker, an Azure DevOps account, and a Kubernetes cluster. You could use Windows Server Core or an Ubuntu container for your self-hosted agent to run inside. However, we will be running our agent inside Kubernetes in order to take advantage of the power of this technology.

To get started, we are going to create a self-hosted Agent Pool in Azure DevOps. This can be done simply in the UI.

We will also need to create a Personal Access Token.

Next, we need to create and build a Dockerfile. A Dockerfile is a text file that contains instructions to build a Docker image. So, we must give the Dockerfile all the information it needs to build the image, including where the directory will be and what executables you need. This is like the recipe for the Docker image. This is also where you would make alterations to your agent’s specifications should your needs change over time.

Once the Docker image is built, push it to a registry, such as Azure Container Registry.

Using Docker, you’re able to avoid the maintenance associated with a self-hosted build agent. You can configure a new Docker image every time you want to spin up an agent. This allows you to create the agent you need, perfectly every single time.

Running Your Agent in Kubernetes

Finally, we need to deploy to Kubernetes using a Deployment manifest. Applying the Deployment manifest will create Azure agents in your Agent Pool. You can check that this was successful by simply viewing your Agent Pools in Azure DevOps.

By provisioning agents this way, you’re able to scale to your needs on demand. Additionally, you can spin up customized agents easily and only have them running as long as you need them.

For more information, or to see how to take advantage of this technology in your organization, contact our team of experts at PRAKTIK here.









Deploy to Kubernetes using Azure DevOps

Modern-day applications are being built using containers more and more often to take advantage of the increased portability and efficiency. As these applications become more complex, they grow to span multiple containers across multiple servers. Kubernetes, an open-source container management tool, helps deploy and manage containers at scale and manage this complexity. In this article, we will discuss how to deploy to Kubernetes using Azure DevOps Services.

Setting up a Kubernetes Cluster

Azure Pipelines can be used to deploy container images to Kubernetes. First, you must set up a Kubernetes cluster. To do this, you can use the Kubectl task to deploy, configure and update a Kubernetes cluster. This task works with Azure Resource Manager and Kubernetes Service Connection. Kubectl is a command-line tool that allows you to manually run commands against Kubernetes clusters. If you are comfortable, you can also use YAML to run these commands. This gives the added benefit of being able to create more complex structures.

Azure Kubernetes Service (AKS) is a simpler way of deploying a Kubernetes cluster in Azure. This service is an open-source and fully managed Kubernetes service that offers an integrated continuous integration and continuous delivery (CI/CD) experience. When you deploy an AKS cluster, the master and all nodes are configured for you. Things like Azure Active Directory integration and monitoring can be configured during the deployment process.

Deploy to Kubernetes

Now that your cluster is set up, you’re ready to get started with your deploying to Kubernetes. Because Azure Pipelines is so flexible, there are several different methods to complete this task. For example, you can simply use the Kubernetes resource view within your environments. This view allows for traceability from the Kubernetes object back to the pipeline, and back to the original commit. This traceability is provided by the KubernetesManifest task. The KubernetesManifest task will also check for object stability and will even deploy according to your deployment strategy.

You can also use Helm to simplify your deployment. Helm is a package manager for Kubernetes that is used to deploy and manage Kubernetes apps. Azure Pipelines has built-in support for Helm charts, so you are ready to go without any additional extensions. For our purposes, the Helm build and deploy task in Azure Pipelines is perfect for packaging your app and deploying it to your Kubernetes cluster.



Kubernetes can be an intimidating tool to use, especially if you’re new to it. There is no shortage of methods to deploy to Kubernetes, but it’s most important to find the method that works best for your team. For more information about deploying to Kubernetes, or to get started today, contact our team of experts.

Mobile App Deployment with Azure DevOps

So you’ve created your mobile application and you’re ready to deploy it to beta testers or maybe even your end users. Whether you want to deploy directly to an app store or to specific users, Azure DevOps and Visual Studio App Center have tools to successfully deploy your app. In this article, we will discuss how to use Visual Studio App Center Distribute to help you deploy your mobile application.

Visual Studio App Center Distribute

App Center Distribute is a powerful option for those who wish to deploy to beta testers, with or without using a public app store. This tool can notify testers of new releases without the requirement of going through the download flow again. As a developer, you can manage distribution groups for your deployment, enabling different rings of testing. For example, you could distribute the app to your internal company testers first before deploying to external testers. In addition, App Center’s open-sourced SDKs and APIs let you integrate your own tools with App Center Distribute. Furthermore, the distribution workflow can be automated using App Center Build and integration with public app stores.

Beyond Deployment

Visual Studio App Center is a collection of tools that allow you to ship high-quality applications quickly and with confidence. Not only are you able to build and test using this tool, you can get insight into how your app is performing after deployment. With real-time analytics and crash reports, you can focus on what’s important and what’s not working. This will help you improve your application, quickly fix problems, and increase your users moving forward. Furthermore, with Azure Application Insights, you’ll be able to dive into advanced analytics and get the information you need to make sure your app is successful.

If you’re ready to get started with deploying your own mobile app, or for questions about mobile deployment, contact our team of experts at PRAKTIK.

Azure DevOps Delivery Plans

With the high volume of projects teams handle today, it is more important than ever that we’re able to keep track of all work items so nothing falls through the cracks. We also must ensure that an individual team’s work aligns with the organizational goals at large. That’s where Azure DevOps Delivery Plans comes in.

What are Delivery Plans?

Delivery Plans 2.0 is a feature in Azure Boards. It is currently natively available in Azure DevOps Services and will be available in Azure DevOps Server 2022. Additionally, Delivery Plans 1.0 is available in the Marketplace as an extension. Delivery Plans shows multiple sprints across multiple teams in a calendar view. With this view you can see the progress of work and adjust as needed to deliver on time. Delivery Plans also supports dependency tracking, with which you can easily determine if there is a dependency issue.

Getting Started with Delivery Plans

There is no bad time to get started with Delivery Plans. Even if you have already planned and started working on a project, the information made available is invaluable moving forward. You should, however, review Agile culture for best practices regarding sprints, autonomous teams, and organizational alignment.

To create your first delivery plan, navigate to your Azure DevOps instance. In the Boards tab, select Delivery Plans. Next, click New Plan. Then, add a plan name and a description, and specify which backlog you want to use. You can also specify the project, the team(s), and field criteria. Once the delivery plan is created, it will show a calendar view of the teams’ backlogs in parallel.


For more information, or to get started with Delivery Plans, contact our teams of experts here at PRAKTIK.

Are You Paying Too Much? Jira vs. Azure DevOps

Early this year, Atlassian altered their pricing model. This alteration resulted in a price increase for Jira users by about 15%. As you can imagine, this came as a blow to some enterprise customers and sent them looking for other options. Azure DevOps Services is one such alternative. In this post, we will discuss examples of comparative pricing between Jira and Azure DevOps Services.

Basic License Cost

Let’s imagine we have an enterprise with 5000 users. At the time of this writing, this number of users with a Jira enterprise license will cost roughly $518,000 USD annually. An Azure DevOps Services basic plan, on the other hand, will cost roughly $359,640 USD annually. It is also important to remember than these costs are, in some ways, not a true comparison. The Jira subscription only comes with Jira. The Azure DevOps basic plan comes with Pipelines, Boards, Repos, and Artifacts.

A cost breakdown of these annual prices per user would show that Jira costs $103.60 USD per user in our example of 5000 users. Azure DevOps Services costs $72 USD per user per year, with the first five users being free. That is more than a 30% difference in annual cost. This cost is offset even further by the fact that Azure DevOps has free stakeholder licenses for users that do not need to be in the code. Furthermore, users with a Visual Studio license also do not need an Azure DevOps license.

Extension Costs

Extensions are a great way to integrate different products together to create a custom solution. If, for instance, you use Jira for project management and Azure DevOps Services for build and release, you can use this add-on from the Atlassian Marketplace to integrate your products.

However, this add-on will cost our team of 5000 users around $30,000 USD annually, in addition to the license cost. This is true even if we want to use this extension for one project with 20 users.

Azure DevOps Services is everything you need to manage your application, from inception to monitoring. Therefore, each piece of the ecosystem is designed to integrate seamlessly, at no additional cost to you.



If you’re wondering whether making the switch from Jira to Azure DevOps Services is right for your team, contact our team of experts at PRAKTIK.

Audit Logs in Azure DevOps Services

Migrating to the cloud from an on-premises instance has many benefits. Specifically, enhanced security, flexibility, scalability, and simplified monitoring. Migrating to Azure DevOps Services in the cloud also offers the ability to access audit logs. Auditing is currently in Public Preview for Azure DevOps Services and is not available on-prem. Audit events can include permissions changes, branch policy changes, and more.

Access Audit Information

To view auditing, simply sign into your organization and select Organization settings. Then, select Auditing. From this page, you’ll be able to view audit information and export it if so desired.



By default, Project Collection Admins are the only ones with full access to auditing features. However, members of the Project Collection Valid Users group can also view and export audit logs.

Review Audit Logs

The audit logs record a ton of information, from the name and IP of the individual who triggered the event to the category and details of the event. Some of this information is viewable from the auditing page. These events must be search by time range. To view events on the auditing page, select the time filter on the top-right of the page. From there, you can select any time range over the last 90 days and narrow down your search to the minute.



However, some information – like the authentication mechanism and correlation IDs – can only be viewed by downloading the logs. Additionally, searching audit events in a downloaded log is more detailed, as you’re able to search by traits like area and category. Furthermore, any information that is older than 90 days must be downloaded to be viewed. To download the audit logs, select the Download button at the top right of the auditing page.

For questions about auditing or your migration into the cloud, contact our team of experts here at PRAKTIK.