Azure Boards - Harness

Hey All!

I’ve had a few conversations around integrations with Harness and other tools, what is and is not supported, and even when certain integrations will be coming. One of the great things about a Software-as-a-Service like Harness is that you get rapid integration support with use-case-directed development.

Obviously, we will need to supplement a stop-gap for some of these integrations in the meantime. The technology integration that this post covers will be Azure Boards.

Azure Information

There are somethings that will need to be brought in from Azure for you to use this integration:

  • Azure Org (i.e. https://dev.azure.com/contoso)
  • Azure Personal Access Token
    • You might want to create a Harness Service Account that can be used for this. It will need Full Access
    • To get the Personal Access Token (PAT) from Azure, follow these steps:
  1. Sign-in to Azure DevOps
  2. Click User Icon in top right
    a. 3 dots and User Settings
    b. PAT
  3. Create PAT with Full Access
  4. Save the PAT somewhere for the time being
  • Azure Work Item information:
    • Work Item Type (Epic, Issue, and Task are the default)
    • Work Item Area
    • Work Item Iteration
    • Work Item States (To Do, Doing, and Done are the default)
    • Work Item Assigned To (Designate someone to be the default user to assign the Work Items to)
    • Work Item Projects

Harness: Secret

Before we get to the templates, we will want to add the Azure PAT into Harness in a way where we can keep it secure. The best way to do this is by adding it to the Harness Secrets Manager two times and then referencing it later.

The first time, we will create in the Secrets Manager as “azure-pat” and the second one will be “azure-pat-delegate” and then select “Scope to Account”.


Harness: Delegate Profile

The easiest way to bring in this integration is to use the Azure CLI. To do this, you’ll need to add the following script into a Delegate Profile:

# Adding Python PIP
echo “ “ && echo "apt-get update" && echo “ “
apt-get update
echo “ “ && echo "install pip" && echo “ “
apt-get -y install python3-pip
echo “ “ && echo "check pip version" && echo “ “
pip3 --version

# Adding AZ-CLI
echo “ “ && echo "install azure cli" && echo “ “
pip3 install azure-cli
echo “ “ && echo "check azure version" && echo “ “
az --version

# Adding ADO Extension
echo “ “ && echo “adding azure devops” && echo “ “
az extension add --name azure-devops
echo “ “ && echo “checking azure devops version” && echo “ “
az extension list

export AZURE_DEVOPS_EXT_PAT=${secrets.getValue("azure-pat-delegate")}
az devops configure --defaults organization=https://dev.azure.com/<org name>

After that is done, you’ll need to assign the Delegate Profile to a Delegate and give it a Tag as well (i.e. az-cli)

The above steps will give the delegate both the Azure CLI, the Azure CLI DevOps Extension, assign the PAT to an Environment Variable, and set the Azure DevOps Organization as the Azure CLI default config (make sure you add your org name to the end of that portion).

Once the CLI is on the Delegate and the Delegate is tagged appropriately, we are ready to move to the actual implementation piece.

Harness: Template Library

Azure Boards uses the term Work Items to indicate the tickets or issues that you can use. As such, we want to be able to create and/or update those Work Items throughout the Harness Workflows and/or Pipelines. Therefore, we will be creating two templates in the Harness Template Library: AZ-Boards - Create Work Item and AZ-Boards - Update Work Item

The template for the Create Work Item is found here.

This template will execute the desired Work-Item Create command and output the Work Item ID into the variable AZURE_WI_ID (for later use). Some things to notice when setting up the template:

  1. Make sure you add the following pieces as variables in the Template Modal:
    a. wiTitle
    b. wiType
    c. wiArea
    d. wiAssignedTo
    e. wiDescription
    f. wiDiscuss
    g. wiProject

You will also need to set AZURE_WI_ID in the Script Output section of the form.

Depending on what defaults you have, you can fill in some parts of the form with static values. Any values you want the users to fill in at runtime can be set as ${workflow.variables.<name>}

Once you have this in the Template Library, you can make the Update Work Item template (found here)

The Update Work Item only has three variables for it:

  1. wiID
  2. wiDiscuss
  3. wiState

As with the Create Work Item template, you can will in some of this information with static values and others with ${workflow.variables.<name>}. Additionally, we will want to set the wiID variable with ${AZ.AZURE_WI_ID} so that the Work Item ID from the Create Work Item piece gets passed into this Update Work Item template.

After both of these are done in the Template Library, you will want to link them in the desired Harness Workflow.

Harness: Workflow

To start off, we will want to make sure that the Workflow Variables are set correctly:
image

Now, we will want to add a step in the pre-deployment part of the Workflow and link the Create Work Item and Update Work Item templates:

.

If you would like to add an approval step to this as well, you can add the Approval Step and use the Custom Shell Script with this script (Make sure that you change the org in the second line and the DESIRED_STATE value if you wan’t something different than Done as your Approval State).

A few things of importance here are:

  1. Add the tag you assigned to the delegate in the Tags section
  2. Check the box that says “Publish output in the context” in the Create Work Item Template
    a. Publish Variable Name = AZURE
    b. Scope = Pipeline
    c.
  3. If you did not fill in the variable values in the Template Library, make sure to do that now

Deployment

(Note: Not all read in the context is bad, so keep that in mind)




Hopefully this helps!

Don’t forget to Like/Comment/Share!

2 Likes

Solid bud like always!