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.

How to Integrate Azure DevOps with GitHub

GitHub is at the heart of the open-source community. So, when it was acquired by Microsoft, the tech giant wanted to ensure seamless integration between GitHub and its own development tools. This integration helps provide an end-to-end development experience. In this post, we’ll talk about how to integrate GitHub with your Azure Boards and Azure Pipelines.

Azure Boards-GitHub Integration

Azure Boards is a tool that allows you to plan, track, and discuss work across your different development teams. GitHub is a cloud-based version control service. Integrating these services means that you’ll be able to plan in Azure Boards without having to go find your commits, issues, or pull requests in GitHub. All the information will be in one place, which will allow for greater productivity.

Starting from GitHub, install the Azure Boards app for GitHub to your GitHub account. Next, select which repositories you’d like to participate in the integration. Finally, approve and install the app. You can also connect Azure Boards to GitHub in the cloud by simply specifying which GitHub repositories to connect to an Azure Boards project.

Starting from Azure Boards is a very similar flow. To begin, add a connection from an Azure Boards project to the GitHub repositories you want to integrate. Then, approve and install the Azure Boards app for GitHub to your GitHub account.


Azure Pipelines-GitHub Integration

Azure Pipelines is a tool that combines continuous integration and continuous delivery to constantly and consistently build, test, and ship your code. By integrating with GitHub, you will be able to continuously deliver value with end-to-end traceability.

First, you’ll need to install the Azure Pipelines extension from the GitHub Marketplace. Then, you need to configure the extension’s access by simply clicking “Configure” next to the Azure Pipelines App in the Installed GitHub Apps tab. You can grant access to all of your GitHub repositories or just specific ones. After this configuration, you’re going to be sent to the Azure DevOps site, where you will specify which organization and project you wish to use. After that, you’ll choose which template to use. Finally, you’re presented with a build pipeline written in YAML that’s ready for you to save and run. Any changes you make to the pipeline will be versioned alongside your code changes.


For any questions, or to get started with your Azure DevOps-GitHub integration, contact our team of experts.

Cut Your Azure Resource Costs in Half

We’re all looking for ways to reduce our development expenses. Sometimes, our expenses are driven up by keeping unused virtual machines, App Services, and SQL Servers in Azure. Alternately, these resources are over-provisioned, meaning we’re paying for more capacity than we actually need. Maybe there are resources you’re not quite sure where they go, but you’re afraid they’re important so you just hang onto them. All of this can increase our subscription costs, particularly for Azure resources in Dev and Test environments. The worst part is that it’s tough to track down these unused resources, especially when the volume of them is so great. So, they end up continuing to run and continuing to eat up cost.

With PRAKTIK’s managed services offering, you can cross this off your to-do list. We will periodically review all your Dev and QA resources to delete any unused items. We will also reorganize and consolidate resources to make sure your subscription costs are where they should be for your use case. Some customers find a 25%-50% decrease in their Azure resource costs by using this service.

At PRAKTIK we realize that every situation is different, so we tailor each managed services offering to meet the needs of each individual client. We can optimize your builds and releases, migrate your Azure DevOps projects, and so much more. If there isn’t a ready-made solution for your problem, we will create it and execute it for you. You will also have your own personal expert to answer any questions that may arise.

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

Azure DevOps Server 2020 Update 1

The most recent update to Azure DevOps Server includes many new features, as well as bug fixes. Some of the highlights include state transition rules in Boards, pull request experience improvements, and generic webhook-based triggers for YAML pipelines. You can directly install Azure DevOps Server 2020.1 or upgrade from Azure DevOps Server 2020, 2019, or Team Foundation Server 2015 or newer. The Data Migration Tool is estimated be available for this update of Azure DevOps Server by the end of June 2021.

State Transition Restriction Rules

The new state transition restriction work item type allows you to restrict work items from being moved to a different state. For example, you can restrict bugs from moving straight from New to Resolved. Instead, they will need to go from New to Active to Resolved. You can also use these restriction rules to restrict state transitions by group membership. This new feature helps to close the feature parity gap between hosted XML and the inherited process model.

Webhook-Based Triggers for YAML Pipelines

In the past, you were unable to automate your deployment process based on external events or services. Now, however, webhook trigger support in YAML pipelines has been enabled to allow you to integrate your pipeline automation with any external service. To learn how to configure your webhooks, see the documentation.

Pull Request Experience Improvements

This update to Azure DevOps Server is full of features to help improve your pull request experience. For example, the tree listing of files in a PR now shows a (+) to help individuals identify new files. Furthermore, aspects of the mobile view have been improved. This includes better usage of space to allow you to view more information. There is also an enhanced branching experience when creating a PR to enable you to compare changes with the compare branch instead of the default branch.

For a comprehensive list of features and bug fixes, visit the documentation. To learn more about installing or upgrading an Azure DevOps Server deployment, contact us at PRAKTIK.

How to Automate Power BI Deployment with Azure DevOps

Power BI is a business analytics solution that allows you to visualize and analyze data. This analysis can be helpful in determining what’s important, and it can be shared to aid in collaboration. In the Power BI service, you can test your content before releasing to customers using Microsoft’s Power BI deployment solution. However, the data in your particular Power BI service may be larger and more complex than the standard deployment solution supports. For these scenarios, PRAKTIK has developed a custom Power BI solution.

Microsoft’s Solution

In order to access the deployment pipelines feature, you’ll need to be an admin of a new workspace or have a Premium license. During deployment, Power BI will copy items such as datasets, reports, and dashboards into the target stage, provided they originate from a PBIX file. However, some items will not be copied, such as the URL, IDs, and certain permissions. Furthermore, the maximum number of Power BI items that can be deployed in one deployment is 300. This Power BI deployment solution is great for simpler, more standard use cases.

PRAKTIK’s Solution

For those scenarios that do require more fine-tuned control, PRAKTIK has developed a custom Power BI deployment solution. For example, we can handle large Power BI reports that are part of a greater app and includes databases, websites, and Power BI reports components. In addition, the solution is fully customizable to your needs. You can even have an environment to roll back any unwanted changes. This deployment will be fully automated, and will only require manual approvals or checkpoints from you if you so desire.

For more information, or to get started with your custom Power BI deployment solution, contact us here at PRAKTIK.

How to Get Azure DevOps Notifications in Microsoft Teams

With an increasing number of people working from home, it’s more important than ever to be able to collaborate effectively with team members. One way to do this is by using Microsoft Teams. In this post, we will discuss how to get Azure DevOps Services notifications directly to your Teams account.

Getting Started

Before beginning, there are a few prerequisites. Firstly, you must have a Microsoft 365 account. It’s also important to remember that only Azure DevOps organizations within the same AAD tenant can be used to integrate with your Teams account. Next, you’ll need to join or create a team within Microsoft Teams. The people on this smaller team could be your other team members, or other people you’re collaborating with.

The Integration

Now, you’re ready to begin the integration of Azure DevOps with Microsoft Teams. From your team page, select Connectors from the ellipses menu on the right. There, you’ll find a list of connectors available for your team. Select the Azure DevOps connector and click Add. Finally, fill in the requested information to configure your connector and save. With Azure DevOps configured, you’ll begin receiving notifications in your Teams channel.


At any point, you can edit the connector for a more personal notification. For instance, here is a sample build failure notification setup.


Other Capabilities

The integration experience doesn’t have to stop with notifications. You can also bring your Kanban board, Dashboard, or even your Pipelines into Microsoft Teams. For more information, or help getting started, contact our team of experts at PRAKTIK today.

Make Your Builds and Releases Faster in Azure DevOps

Are your Azure DevOps builds and releases taking forever to run? A lot of things have to go on behind the scenes for a successful deployment. For example, hardware must be allocated for your deployment. If you’re using a public pool of servers, or even a pool of your own, this can take some time. Additionally, build and release pipelines may not be as streamlined as they could be, therefore making everything take just a bit longer. In today’s world, time is precious. Let PRAKTIK Group make your builds and releases faster to give you some time back.

PRAKTIK’s Optimization Service

PRAKTIK is offering this optimization service is offered to our managed services customers. It follows a two-pronged approach. First, we will utilize optimized build machines that take advantage of data caches and RAM disks. This can be done using our infrastructure or your own. No matter which infrastructure you choose, our team will make sure it is refined for your specific use case.

Next, our team of experts will optimize your deployment process. To do this, we will implement a modern branching strategy and eliminate unnecessary artifacts from the build process. Furthermore, we will reduce the number of build and release pipelines required to build your application. All of this can dramatically reduce the time you spend waiting, which means more time available for testing and perfecting your application.

Getting Started

Getting started with our optimization service is as simple as sending an email or picking up the phone. Simply contact us, and our team will provide you with the expert service you need.

How to Move Data Between Azure DevOps Instances

When it comes time to transfer data between Azure DevOps instances, it is important to understand the benefits and limitations of each type of transfer. Data can be moved on an instance level and a project level within Azure DevOps. It can also be moved from Azure DevOps Server on-premises to Azure DevOps Services in the cloud. In this post, we will discuss each type of transfer, as well as scenarios in which each may be appropriate.

Instance Level Transfer Within Azure DevOps Services

In this type of transfer, ownership of data is moved between organizations from one Azure DevOps cloud instance to another. We might also see this during a subscription ownership transfer, or when moving Azure DevOps users from one Active Directory domain to another. This type of transfer is quite simple and doesn’t require major changes. The move can be completed in less than an hour and will require a minimum of two days of planning and preparation.


Lift-and-shift On-Premise Collection to Azure DevOps Services

This is a slightly more complicated data transfer. Here, data is moved from an on-premises collection to a cloud instance. It is a lift-and-shift operation, but there are some limitations. For example, rarely-used work item template elements like state transition rules may not be migrated. Furthermore, you may decide to make minor changes before the lift, such as refactoring your application in order to make it work more effectively in the cloud. This type of move is executed over a weekend to minimize downtime and will need between one and three weeks for planning, preparation, and dry run. The time required depends on the size of the collection, the level of customization, and the current on-prem version.


Migrate Project Data Between Azure DevOps Instances

This is the most effort-intensive data transfer. This might be used during a company split, reorganization, or acquisition in which Azure DevOps instances need to be divided or consolidated. Lift-and-shift is not a viable option here, as we cannot simply move a copy of the data as it is. Work item IDs will change during the migration. In addition, pull requests and history of Pipelines and Releases cannot be transferred. Similarly, TFVC Source Control history can only be migrated to a Git repository. This type of move is executed over a weekend to minimize downtime and it will need between two and six weeks for planning, preparation, and dry run. The time required depends on the amount of data to be transferred and the level of customization of the Azure DevOps Instance.

Need some help with your transfer? Not sure where to start? Contact our team of experts today.