Categories
Azure DevOps

How to generate an Azure DevOps pipeline status badge for README files

Microsoft has made it very easy to generate badge icons that you can use wherever you’d like, showing the status of your build and release pipelines in Azure DevOps.

The icons – which are made available as images – can be generated for both build pipelines and release pipelines on the Azure DevOps website. They change based on the outcome of the latest run, allowing you to place them in places such as your project’s Readme files.

They aren’t particularly flexible, but you can choose the branch and scope of the success/fail status.

How to generate a badge icon

Login to the Azure DevOps portal. Navigate to Pipelines, and then choose the release or build pipeline that you would like to generate an icon for.

In the top right-hand corner, select the three dots and then choose “Status badge”.

This brings up a modal window that allows you to customise the badge, and choose a branch, scope for the status (pipeline or per job), and then a URL is generated for the image.

Microsoft also provides the markdown text which allows you to immediately copy and paste the badge into a markdown file such as your project’s Readme file.

Categories
Azure DevOps

How to link Azure DevOps with Jira

In this post, we’ll look at the official integration between Azure DevOps and Atlassian’s Jira software.

Love it or hate it, Jira is among other things one of the most widely used issue tracking tools, and in July 2019 Microsoft rolled out a new Jira app that can be used to sync issues between DevOps and Jira, enabling end to end traceability between both platforms from when an issue is reported to when a deployment is released fixing it.

There are a number of limitations. At present, the official plugin doesn’t support DevOps repositories. Only GitHub repositories are supported, although Azure Repos support is planned soon. Build information also isn’t available – the app will only show deployments made in the Jira issue.

The integration also doesn’t change much from DevOps – there’s no UI integrating with Jira reporting or issues, and you can’t easily view a summary of Jira cards from pull requests commit messages.

That said, to get started, you’ll need to:

  • Be a Jira administrator, or have the ability to request a Jira app be installed within your organisation’s Jira installation
  • Use Jira Cloud – on-premise installations aren’t supported
  • Use GitHub for your source code

It’s also worth noting that for now this app only supports showing deployment traceability in Jira – other information such as build numbers or tasks will not show.

Getting started

First you’ll need to install the Azure Pipelines for Jira application, available for free in the Atlassian marketplace.

Then, once you’ve installed the app you’ll be prompted to add your DevOps organisation. Click “Add organisation”, and you’ll be prompted to enter your credentials. It should then list all your organisations in a table view.

Enabling support in DevOps

Now we need to add the Jira integration to our DevOps release pipeline. Open the DevOps portal, and navigate to your project and release pipeline.

Click “Edit” on the release pipeline you’d like to integrate Jira with, and then click “Options”. Click “Integrations” and you’ll see the option to “Report deployment status to Jira”.

Check the box, and you should see your Jira software cloud account listed from the previous step. If you don’t see it, check your Jira account to make sure you’ve added the organisation successfully in the DevOps app.

You’ll also see the ability to map your stages to a set list of deployment types. These deployment types are set by Microsoft, and you’ll have to pick from the list and match them as best you can to your stages. At present, there are 5 deployment types:

  • Production
  • Staging
  • Testing
  • Development
  • Unmapped

These deployment types then show in your Jira cards as commits which contain your story numbers move through your deployment process.

Referencing Jira issues

The app works by searching your commit history (both commit and pull request messages) for Jira issue keys. If you’re not sure about how to find an issue key see this article on Atlassian’s website.

To enable the linking, once you’ve followed the above steps simply add the issue number into your commit messages when you write them. We tend to stick to the format “[ISSUE-KEY] Fixed an issue with something” as the short message title, but the exact format is up to you.

The app then searches your commit history and will automatically update the issue when you create and deploy a release in your pipelines. It’s that simple.

Categories
Azure DevOps

How to delete an Azure DevOps project

In this post we’ll look at how to delete an Azure DevOps project.

First, you’ll need to login with your account to the DevOps portal. Choose the organisation that contains the project you want to delete from the left-hand sidebar, and then select the project you want to delete.

Then, once you’re on the homepage for the project you wish to delete, click “Project Settings” in the bottom left-hand corner. If you don’t see this option you may not have the required permission to manage the project.

Navigate to the General > Overview screen in Project Settings and scroll to the very bottom. A big red “Delete” button should appear at the bottom.

Click “Delete” and you’ll be asked to enter type your project name to confirm the deletion. Type the name of the project in the textfield, click “Delete” and your project removed.

Note that it won’t actually be deleted immediately – it will be placed in a temporary recycling bin for 28 days before being permanently removed. This gives you time to change your mind about the deletion, for example if you removed the wrong project or need access to the information again. After the 28 days the information will be permanently erased.

Categories
Azure DevOps

Using key vault values from variable groups in Azure DevOps pipeline tasks

Earlier this week we had a post about how you can easily access secrets stored within Azure Key Vault in an Azure DevOps pipeline task, using the Key Vault Task. One other way you can achieve this same functionality is by using a variable group, and in this post we’re going to show you how.

Why would you use a variable group instead of the key vault task? If you know you require access to the secrets from across multiple stages within a pipeline using a group allows you to easily manage access without having to include the task in every single stage by scoping the group to the release or specific stages.

However, if only one stage requires access to the secrets it might be easier to just include the task in that particular stage and follow our previous post.

Getting started

First you’ll need to setup your key vault so that your service principal or managed identity has GET access to your vault. Then, follow our previous post on creating a variable group with a key vault to setup DevOps for this integration.

Once you’ve done the above, it’s time to get started. Navigate to your release pipeline in Azure DevOps.

Connecting the variable group

From your release pipeline, click “Edit”. Go to the “Variables” tab at the top of the screen, and choose “Variable groups”.

Select the variable group you created in the above section, scope it to either the entire release or a stage of your pipeline (depending on where you need to have access to the secrets, keeping in mind the more restricted you can make it the better from a security perspective) and click “Save”.

Now from within your tasks, if you need to reference the secrets you can use the $(your-variable-name) syntax. For instance, in the Azure Function App Deploy task, if we wanted to specify an app setting under “Application and Configuration Settings” we could use the following syntax:

-NOTIFICATIONHUB_CONNECTIONSTRING $(your-connection-string-secret-identifier)

The benefit of this is that the syntax is identical to that used with the key vault task (they both set the secrets as task variables) so if you need to, you can swap between using a variable group or key vault task with ease.

Summary

In summary, this is an alternative approach to using the key vault task in a pipeline. Depending on your needs, this may be a better approach than the other lesson, but mileage may vary.

Categories
Azure DevOps

Accessing Key Vault secrets in an Azure DevOps pipeline task

In the post, we’ll take a look at one option for accessing Azure Key Vault secrets from within an Azure DevOps release pipeline.

Want to secure your Azure DevOps application secrets in Key Vault? Find out how in  our short e-book guide on Amazon

Setting up your Azure Key Vault

Before you can add the secret to your pipeline, you first need to make sure that there’s a key vault setup in Azure, and that you have given either your pipeline managed service identity or account GET access to the secrets within the vault. Note that you need to ensure this is set under your key vault’s “Settings” → “Access Policies” section.

If you haven’t already, add your secrets into the “Secrets” section, and take note of the names used for the secrets – you’ll need these a bit later on.

Adding the Azure Key Vault pipeline task

Now that you’ve got your secrets stored and accessible from key vault, it’s time to configure the Dev Ops pipeline. Open the visual pipeline editor for your pipeline by clicking “Edit”, and choose the stage in which you need access to the secrets.

Then, click the “+” button next to “Run on agent” (or whatever the first step of your pipeline may be) and search for “Azure Key Vault”. Note that you’ll want to add the “Download Key Vault Secrets” task that appears first – this is the official task from Microsoft.

Then, click on the new “Azure Key Vault” task you just added to your pipeline, and set a display name. Choose the Azure subscription in which you created your key vault, and then select from the “Key vault” dropdown list the name of the key vault you stored your secrets in.

If you can’t see it listed, it’s possible you managed service identity doesn’t have the correct permission, so be sure to check it’s been added to your key vault with GET permission.

Now drag the key vault task up your pipeline task list (if applicable) so that it runs before any other task that requires a secret stored within your key vault.

And that’s it!

Accessing a Key Vault secret from other tasks

Now other tasks can access the secrets, by using a task variable. The key vault task will make all your secrets available using the $(<your secret name here>) syntax, such as $(api-secret).

Summary

This is just one of the various ways that you can access key vault secrets from a Dev Ops pipeline task. Stay tuned for more posts where we explore other ways of accessing the secrets in tasks.

If you want a more in-depth guide and comparison between alternative approaches to storing secrets in DevOps, you can also get our book on Amazon today.

Categories
Azure DevOps

How to use variable groups in Azure DevOps

In a previous post looking at how to use Azure Key Vault to store secrets for a DevOps pipeline, we touched on variable groups and how they can be used. In this post, we’re going to dive a bit deeper into what a variable group is, how you can create one and how you can link variable groups into your build pipeline.

Want to secure your Azure DevOps application secrets in Key Vault? Find out how in  our short e-book guide on Amazon

What is a variable group?

A variable group is a logical collection of environment variables (or properties) used throughout your build and/or deployment pipelines. They are essentially key value pairs, that can include things like API keys, database connection strings or configuration items such as downstream API endpoint URLs.

Variable groups can store both plain text variables and secrets, which should never be committed into your source code repository. Note that if you want to use DevOps’ Azure Key Vault integration, you’ll need to create a separate variable group as you can’t mix and match Key Vault and DevOps variables in the same group.

How do I create one?

Creating a variable group is simple. Login to Azure DevOps and navigate to “Pipelines” > “Library”. You’ll see in the top navigation bar the option to “+ Variable Group”. Clicking that will take you to a “New variable group” screen, that asks for a number of properties:

  • Variable group name: A friendly name used to refer to your new variable group. Use something that has meaning to you and the types of properties that will be stored within the group (ie. My App – Production)
  • Description: Provide a short description that describes a bit more about the types of variables that should be placed within this group (eg. This group contains build settings and environment variables for production builds only)
  • Allow access to all pipelines: Enable this toggle to ensure that you can access all the variables from all of your pipelines. If you don’t enable it, you’ll need to authorise pipelines defined in YAML manually in order to let them access your properties.
  • Link secrets from an Azure key vault as variables: Enable this toggle if you want to use Azure Key Vault to store your secrets instead of DevOps. Note that by enabling this, you’ll need to then provide key vault connection details, and enter your secrets via the Azure Portal instead.

If you left the key vault integration disabled, you’ll now be able to click “Add” below the “Variables” section to begin creating new properties. Each property can have a name and a value, and can be marked as clear text or secret by clicking the padlock icon at the end of each row.

If you need to customise security permissions, click “Security” at the top of the screen. This will bring up a modal window where you can add or remove user groups from being able to access this variable group.

Once you’re done, hit “Save” and your variable group will be persisted.

How do I use it?

If you selected “Allow access to all pipelines” when creating the variable group, linking it with your build pipeline through the DevOps website is simple. Navigate to the pipeline you want to link the group with, click “Edit” in the top-left corner and then click “Variables” underneath your pipeline name.

You should see on the left-hand side “Pipeline variables” and “Variable groups”. Navigate to the latter, and click “Link variable group”. This brings up a modal that lists all the variable groups that your role has access to – if you can’t see a group that you know exists, check to make sure you have set the right permissions in the “Security” window for that group.

Choose the group you want to link with the pipeline, and then the scope that the group applies to. If the variables are used throughout the pipeline, then you can choose to make it visible to the entire release, or if you know only a few scopes require access you can also choose specific scopes.

Click “Link” and you’ve now made the variable group be accessible from your pipeline!

Alternatively, if you’re using a YAML file to describe your pipelines and builds, you can also add a variable group by adding the following section in your YAML file:

variables:- group: your-new-variable-group-name

One thing worth noting is that when you run a pipeline, DevOps will create an immutable snapshot with the values of the variables within your group so that your release remains in the same state. This ensures that it isn’t influenced by future changes or modifications that you might make to the values, and means you can redeploy a release later if needed.

Summary

Variable groups can be powerful tools for logically grouping properties and secrets that you need for build pipelines, and are simple to configure and use.