Categories
Azure DevOps

Setup Azure DevOps organisational portfolio dashboards

Looking to setup Azure DevOps organisational dashboards? This is harder than it probably should be today. At present there’s no notion of cross-project widgets or organisational status views. There is a user feedback request, but it has been ‘under consideration’ for years.

In leu of that, here are some options for getting a view of how your teams are going across multiple projects.

Using PowerBI and OData

One option for creating your own reports and dashboards is to use OData support in PowerBI to import data via the Azure DevOps APIs.

While an option for the more technical-minded – at least initially during the setup phase – this is a great way to explore your DevOps data without paying a premium for a third-party solution if you already have PowerBI setup.

Cross-project queries

This is another more technical approach, but you can create queries under Azure Boards that allow you to query across multiple projects. This in turn allows you to build charts and dashboards using widgets.

With this approach though you’ll need to pick one project to host your cross-project dashboards – there’s no way to have an organisational dashboard as yet.

Portfolio overview

If you’re looking to get a view of how your portfolios are going across projects, then there is a free third-party tool available – Portfolio++.

You can upgrade to the paid PRO version to unlock additional program management functionality, but the free version allows you to create cross-project roadmaps, filter through epics and boards and more.

DevOpSmartBoard

If you need more than just cross-project portfolio management, then this plugin could be for you. It is a paid plugin (at the time of writing ~$40USD per year, per user) but it offers perhaps the most comprehensive out of the box cross-project reporting solution.

It supports organisational level reporting across boards, CI/CD pipelines and more. You can drill down into charts and even traceability reports.

If you’re after a more practical experience – ie. a developer who wants to see all pending pull requests across multiple projects, then this probably isn’t for you. But if you’re a program or portfolio manager, then there’s a lot to like here.

Categories
Azure DevOps Cloud

How to fix Azure MissingSubscriptionRegistration error

Are you trying to deploy an Azure Resource Manager (ARM) template and getting the error MissingSubscriptionRegistration? In this article we’ll take a look at what the cause of the error is, and how you can easily rectify the problem.

Sometimes when trying to run an ARM template in a new subscription to create Azure resources, customers come across the following error:

MissingSubscriptionRegistration: The subscription is not registered to use namespace 'Microsoft.Web'

The namespace may be different depending on the resources you’re trying to create – but effectively this error is telling you that for your subscription, you cannot create resources belonging to the aforementioned namespace. In the case of this example, that’s Microsoft.Web – specifically an App Service.

By default, a new subscription will have most resource providers disabled as a precautionary security measure. You can see a full list of default enabled providers here.

By having most providers disabled, compromised accounts are unable to create a raft of resources. Therefore it’s critical that you only enable namespaces you need to use.

Normally deploying an ARM template should automatically enable the resource namespace – but sometimes it doesn’t work as expected. Similarly, creating a resource manually in the Azure portal should also automatically enable the resource namespace.

Fixing this error is quite straightforward, assuming you have owner or contributor access to the subscription. If you don’t, you’ll need to get your IT administrator to make these changes on your behalf.

Open the Azure Portal, navigate to Subscriptions and choose the subscription you’re trying to deploy the ARM template into. Then, go to Resource providers in the sidebar.

Now scroll through the list of all resource providers until you see the one mentioned in the error message you received. Click the namespace to highlight it, and then choose Register from the menu bar.

This will now activate the namespace, allowing you to create resources that reside within it and thereby the error will be resolved.

Note however that the namespace may not be activated immediately – you may need to wait up to 15 minutes before running the ARM template deployment again.

The registering status shows in the portal while the namespace is being activated – so a quick refresh of the page will allow you to see when the work is completed.

Categories
Azure Azure DevOps

Getting started with Azure Bicep

Bicep is a new language from Microsoft that allows you to easily specify your Azure infrastructure as code.

It’s an improvement on writing Azure Resource Manager (ARM) templates directly by better supporting features such as type safety and code modularity and reuse.

That said, Bicep still has a very close relationship with ARM templates. In fact, it’s an abstraction over ARM templates with templates written using Bicep able to be transpiled back to ARM templates. And if you have a bunch of existing ARM templates, they can be transpiled and converted into Bicep files.

Let’s now take a look at how you can get started using Bicep.

Preparing your environment

There’s a few things you’ll want to install in order to start using Bicep.

First you’ll want to download Visual Studio Code (free) and install the Bicep extension (also free). This will give you an editor in which to write your Bicep files, and the extension adds handy features such as Intellisense code suggestions and template validation to ensure the correct syntax.

You’ll also need to install the Bicep command line interface (CLI). The easiest, cross-platform way to do this is by installing the Azure command line interface. But if you’re after an alternative, see this list.

Become a Bicep guru

Dive deeper into Bicep with our getting started with Bicep course on Udemy today!

Writing your first Bicep file

Open Visual Studio Code, and create a new file called HelloWorld.bicep. In it, paste the following code:

resource appConfig 'Microsoft.AppConfiguration/[email protected]' = {
  name: 'bicepDemoAppConfig'
  location: 'westus2'
  sku: {
    name: 'standard'
  }
}

In this template, we’re creating an App Configuration service in Azure. Lets breakdown the template:

appConfig provides a local resource name for use within the template if you need to refer to this resource as a dependency, or from within another resource.

Microsoft.AppConfiguration/[email protected] refers to the resource type and the values that can be configured. See this Microsoft documentation for a full list of resource types.

As such, name, location and sku are all values that can be set for the resource type.

Next steps

To learn how to deploy this template, or to find out about more advanced Bicep topics including for loops, conditional statements and modularised templates check out our Udemy course on getting started with Bicep.

Categories
Azure DevOps

How to fix Azure DevOps library group permission errors

Are you trying to edit a variable group in an Azure DevOps Library, and getting the error “you do not have permission to create a variable group within library“? Continue on to find out how to rectify this issue.

The problem

DevOps project settings – these don’t apply to variable groups

Variable groups within Azure DevOps can have different permissions to your project settings. This can be useful to limit the number of people who can view and edit your config values, but can be confusing.

As such, while you may have appropriate permissions to edit and your project you may find yourself unable to create variable groups within your Azure DevOps instance.

If this has happened to you, you’ll be shown an error something along the lines of “Error: you do not have permission to create a variable group within library.”

The fix

Luckily there’s a quick fix to this issue, although it will require you to find someone with the correct administrator privileges first.

Once you’ve found the person who has the correct privileges, navigate to your project in the DevOps portal, and create a new group. Alternatively, if this is an existing group click on the title of the group you wish to edit.

If you did create a new group, name it and make sure at least one variable exists. Note that this can be a dummy value – but without a variable DevOps won’t let you save the new group.

Then, within the edit group screen, select “Security“. The title of the modal that appears should be something like “Assign security roles for Library/<your group name>”. If it’s not, make sure you selected the group first and that you haven’t clicked “Security” from the main Library screen.

Security roles apply to variable groups

DevOps libraries have 3 tiers of roles/permissions:

  1. Reader: Can only view items within the library
  2. User: Can use items within the library, but can’t edit them
  3. Administrator: Can use AND manage items within the library

Search for the user(s) you want to be able to add and edit variables (and to avoid the above error) and choose the “administrator” role.

Click “Add”, close the modal and then click “Save”. The above error should no longer occur for users trying to edit or create variables in the DevOps library.

Categories
Azure DevOps

Azure DevOps system variables now read-only

Azure DevOps provides a number of predefined system variables out of the box on hosted build agents.

While these have officially always been read-only, informally you’ve previously been able to change the value of a predefined system variable by overwriting it in a pipeline task.

However, as of the January 28 2020 DevOps release this is no longer the case. The DevOps team have improved the security of system variables, and as such now actively prohibit system variables from being written to.

The variables include items such as the DefaultWorkingDirectory, JobName and TeamProject. These are all variables that you can otherwise use and refer to in your DevOps pipeline tasks.

This means you’ll need to now create your own task or pipeline variables where possible. If you can’t modify the task or pipeline variables, speak to someone with admin rights who can.

Categories
Azure DevOps

How to retry a failed stage in Azure DevOps

One of the biggest limitations of Azure DevOps has until now been the fact that you can’t retry an individual stage or step in a pipeline if it fails. Instead, you’d have to retry the entire pipeline again and hope that the failed stage passes.

As of September 2019, in most cases you can now retry a failed stage without the need to retry the whole pipeline – but there’s a catch. You’ll need to enable the Multi-stage pipelines preview feature, if you haven’t already. Note that this still doesn’t allow you to retry failed steps within a stage – rather it relies on the new multi-stage support to allow you to retry a collection of steps within a stage.

You can check if this is enabled by clicking your avatar in the top-right corner of the Azure DevOps portal, and then “Preview features”. Select “for this organisation [<your organisation name]” from the drop-down menu at the top of the screen, and scroll down until you see “Multi-stage pipelines”. If this is toggled off, you’ll need to turn this on before you can retry failed stages – you will need administrator rights to change it though.

Once you’ve enabled this, navigate back to your release pipelines and you should see the ability to re-rerun individual stages that fail throughout your pipeline.

Note that as this is still in beta, there are some limitations. Perhaps one of the biggest is that you can’t retry stages that are explicitly cancelled – only those that fail as a result of the task being run having an error can be retried today.